[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |