Re: [Xen-devel] [PATCH 3/3] vVMX: use latched VMCS machine address

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.02.16 at 07:50, <liang.z.li@xxxxxxxxx> wrote:
>>  thanks for the analysis!
>> 
>> > (XEN)nvmx_handle_vmclear
>> > (XEN)nvmx_handle_vmptrld
>> > (XEN)map_io_bitmap_all
>> > (XEN)_map_io_bitmap
>> > (XEN)virtual_vmcs_enter
>> > (XEN)_map_io_bitmap
>> > (XEN)virtual_vmcs_enter
>> > (XEN)_map_msr_bitmap
>> > (XEN)virtual_vmcs_enter
>> > (XEN)nvmx_set_vmcs_pointer
>> > (XEN)nvmx_handle_vmwrite
>> > ....
>> >
>> > so the virtual_vmcs_enter() will be called before the
>> > nvmx_set_vmcs_pointer(),
>> > and at this time   'v->arch.hvm_vmx.vmcs_shadow_maddr' still equal to 0.
>> 
>> So this finally explains the difference in behavior between different
>> hardware - without VMCS shadowing we wouldn't reach
>> virtual_vmcs_enter() here.
>> 
>> > Maybe  ' v->arch.hvm_vmx.vmcs_shadow_maddr' should be set when
>> setting
>> > the 'nvcpu->nv_vvmcx'  in nvmx_handle_vmptrld().
>> 
>> Right, this looks to be the only viable option. In particular, deferring
>> map_io_bitmap_all() and _map_msr_bitmap() cannot reasonably be moved
>> past nvmx_set_vmcs_pointer(), since failure of any of them would then
>> require further unrolling, which seems undesirable. Plus doing it this way
>> allows undoing some of the changes done before.
>> 
>> Attached the updated patch - could you please give this another try (on top
>> of current staging or master)?
> 
> This version work well on HSW-EP on top of the current master, no obvious 
> issue was found.

And that was also where things didn't work before?

Thanks for your help with this!

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel