Re: [Xen-devel] [PATCH v5 0/4] nested vmx: enable VMCS shadowing feature

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.01.13 at 09:39, Dongxiao Xu <dongxiao.xu@xxxxxxxxx> wrote:
> Changes from v4 to v5:
>  - Change the size for vvmcs buffer from 500 to 100.
>  - Store page_info in per-pCPU structure instead of MFN in per-vCPU structure 
> for vmread/vmwrite bitmaps.
>  - Define correct data type to avoid force type conversion.

Looks good to me now, so I guess all that's needed is an ack from
Jun or Eddie, and a check of yours that this still applies to the tip of
the staging tree.

Jan

> Changes from v3 to v4:
>  - Allocate a buffer in initialization time for data exchange instead of 
> runtime allocation (reflect Jun's comment).
>  - Move the vmread/vmwrite bitmap logic into nvmx_vcpu_initialise(), also 
> track MFN instead of virtual address in the vcpu global data. (reflect Jan's 
> comment).
> 
> Changes from v2 to v3:
>  - Use pfn_to_paddr() to get the address from frame number instead of doing 
> shift directly.
>  - Remove some unnecessary initialization code and add "static" to 
> vmentry_fields and gpdptr_fields.
>  - Enable the VMREAD/VMWRITE bitmap only if nested hvm is enabled.
>  - Use clear_page() to set all 0 to the page instead of memset().
>  - Use domheap to allocate the VMREAD/VMWRITE bitmap instead of xenheap.
> 
> Changes from v1 to v2:
>  - Use domain_page_map_to_mfn() instead of virt_to_mfn() to get the machine 
> frame.
>  - Address other comments from Jan, including some programming format, return 
> value type, etc.
> 
> Latest Intel SDM introduced a new feature "VMCS shadowing" at bit 14 in
> Secondary Processor-Based VM-Execution Controls for nested virtualization.
> 
> The main purpose of this feature is to reduce or eliminate the number of VM 
> exit
> for non-root VMREAD and VMWRITE. It provides the capability to link a
> "virtual VMCS" with the current running VMCS, so that after VM entry, the
> non-root VMREAD and VMWRITE can get/set related data directly from/to the
> "virtual VMCS" without trap and emulation.
> 
> A separate bitmap is introduced for VMREAD and VMWRITE, from which 
> hypervisor
> can control whether VMREAD/VMWRITE from/to certain VMCS field will trigger
> VM exit or directly get/set data by hardware.
> 
> With the new feature introduced, all the in "virtual VMCS" need to be 
> operated
> by VMREAD and VMWRITE because this VMCS will also be loaded into hardware.
> This requires the capability to VMWRITE all the VMCS fields, including those
> readonly ones. Intel SDM introduces this functionality at bit 29 in
> IA32_VMX_MISC MSR.
> 
> For details, please refer to:
> http://www.intel.com/content/www/us/en/processors/architectures-software-devel
>  
> oper-manuals.html
> 
> Thanks,
> Dongxiao
> 
> Dongxiao Xu (4):
>   nested vmx: Use a list to store the launched vvmcs for L1 VMM
>   nested vmx: use VMREAD/VMWRITE to construct vVMCS if enabled VMCS
>     shadowing
>   nested vmx: optimize for bulk access of virtual VMCS
>   nested vmx: enable VMCS shadowing feature
> 
>  xen/arch/x86/hvm/vmx/vmcs.c        |   48 ++++++
>  xen/arch/x86/hvm/vmx/vvmx.c        |  324 
> ++++++++++++++++++++++++++++++++----
>  xen/include/asm-x86/hvm/vmx/vmcs.h |   23 +++-
>  xen/include/asm-x86/hvm/vmx/vvmx.h |   24 +++-
>  4 files changed, 383 insertions(+), 36 deletions(-)




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