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

Re: [Xen-devel] [PATCH v1 0/6] VMX MSRs policy for Nested Virt: part 1



> From: Sergey Dyasli [mailto:sergey.dyasli@xxxxxxxxxx]
> Sent: Monday, June 26, 2017 6:44 PM
> 
> The end goal of having VMX MSRs policy is to be able to manage
> L1 VMX features. This patch series is the first part of this work.
> There is no functional change to what L1 sees in VMX MSRs at this
> point. But each domain will have a policy object which allows to
> sensibly query what VMX features the domain has. This will unblock
> some other nested virt work items.
> 
> Currently, when nested virt is enabled, the set of L1 VMX features
> is fixed and calculated by nvmx_msr_read_intercept() as an intersection
> between the full set of Xen's supported L1 VMX features, the set of
> actual H/W features and, for MSR_IA32_VMX_EPT_VPID_CAP, the set of
> features that Xen uses.
> 
> The above makes L1 VMX feature set inconsistent between different H/W
> and there is no ability to control what features are available to L1.
> The overall set of issues has much in common with CPUID policy.
> 
> Part 1 introduces struct vmx_msr_policy and the following instances:
> 
> * Raw policy (raw_vmx_msr_policy) -- the actual contents of H/W VMX MSRs
> * HVM max policy (hvm_max_vmx_msr_policy) -- the end result of
>                                nvmx_msr_read_intercept() on current H/W
> * Per-domain policy (d->arch.vmx_msr) -- the copy of HVM max policy
>                                          (for now)

confirm here. So per-domain policy is what you plan to use to
solve inconsistency issue in the future? to make the description
complete, you may want to elaborate a bit for future usages
of new knobs.

> 
> There is no "Host policy" because Xen already has a set of variables
> (vmx_pin_based_exec_control and others) which represent the set of
> VMX features that Xen uses.  There are features that Xen doesn't use
> (i.g. CPU_BASED_PAUSE_EXITING) but they are available to L1.  This makes
> it not worthy to introduce "Host policy" at this stage.
> 
> Sergey Dyasli (6):
>   vmx: add struct vmx_msr_policy
>   vmx: add raw_vmx_msr_policy
>   vmx: refactor vmx_init_vmcs_config()
>   vvmx: add hvm_max_vmx_msr_policy
>   vvmx: add per domain vmx msr policy
>   vmx: print H/W VMX MSRs values during startup
> 
>  xen/arch/x86/domain.c              |   6 +
>  xen/arch/x86/hvm/vmx/vmcs.c        | 639
> ++++++++++++++++++++++++++++++++-----
>  xen/arch/x86/hvm/vmx/vmx.c         |   4 +
>  xen/arch/x86/hvm/vmx/vvmx.c        | 309 +++++++++---------
>  xen/include/asm-x86/domain.h       |   2 +
>  xen/include/asm-x86/hvm/vmx/vmcs.h | 346 ++++++++++++++++++++
>  xen/include/asm-x86/hvm/vmx/vvmx.h |   3 +
>  7 files changed, 1070 insertions(+), 239 deletions(-)
> 
> --
> 2.11.0


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

 


Rackspace

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