>>> On 22.03.18 at 12:32, <sergey.dya...@citrix.com> wrote: > 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 virtualization 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 adds VMX MSRs into struct msr_domain_policy and initializes them > during domain creation based on CPUID policy. In the future it should be > possible to independently configure values of VMX MSRs for each domain. > > v5 --> v6: > - Various shortenings of control bit names > - Added Reviewed-by: Andrew Cooper to pathes 3,4 and 5 > - Other changes are provided on per-patch basis > > Sergey Dyasli (5): > x86/msr: add VMX MSRs definitions and populate Raw domain policy > x86/msr: add VMX MSRs into HVM_max domain policy > x86/cpuid: update signature of hvm_cr4_guest_valid_bits() > x86/msr: update domain policy on CPUID policy changes > x86/msr: handle VMX MSRs with guest_rd/wrmsr()
Provided there's going to be a R-b by one of the VMX maintainers, Acked-by: Jan Beulich <jbeul...@suse.com> Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
