[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v1 5/6] x86/vvmx: correctly report vvmcs size



> From: Sergey Dyasli [mailto:sergey.dyasli@xxxxxxxxxx]
> Sent: Tuesday, October 30, 2018 8:36 PM
> 
> On 30/10/2018 08:06, Tian, Kevin wrote:
> >> From: Sergey Dyasli [mailto:sergey.dyasli@xxxxxxxxxx]
> >> Sent: Friday, October 12, 2018 11:28 PM
> >>
> >> The size of Xen's virtual vmcs region is 4096 bytes. Correctly report
> >> it to the guest in case when VMCS shadowing is not available instead of
> >> providing H/W value (which is usually smaller).
> >
> > what is the problem of reporting smaller size even when actual
> > size is 4096? is L1 expected to access the portion beyond h/w
> > reported size?
> >
> 
> Here's the code snippet from kvm-unit-tests:
> 
>       vmcs[0]->hdr.revision_id = basic.revision;
>       assert(!vmcs_clear(vmcs[0]));
>       assert(!make_vmcs_current(vmcs[0]));
>       set_all_vmcs_fields(0x86);
> 
>       assert(!vmcs_clear(vmcs[0]));
>       memcpy(vmcs[1], vmcs[0], basic.size);
>       assert(!make_vmcs_current(vmcs[1]));
>       report("test vmclear flush (current VMCS)",
> check_all_vmcs_fields(0x86));
> 
> set_all_vmcs_fields() vmwrites almost 4k, but memcpy() copies only 1024
> bytes and vmreads get incorrect values.
> 

I didn't understand why set_all_vmcs_fields blindly touch 4k instead of
following reported size. Also I didn't get the reason of this patch - whatever
size reported, xen just needs to emulate hw behavior according to spec,
i.e. do proper emulation if offset < size, otherwise just vmfail. Guest is
not aware of shadow vmcs. why do we want to report different vmcs
size based on presence of shadow vmcs?

Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.