>>> On 07.06.16 at 12:18, <euan.har...@citrix.com> wrote: > Guest reads of MSR_IA32_VMX_VMFUNC should be handled by > the logic in vmx_msr_read_intercept(). Otherwise a guest > can read the raw host value of this MSR, even if nested > vmx is disabled. > > Signed-off-by: Euan Harris <euan.har...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com> Albeit ... > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -2624,7 +2624,7 @@ static int vmx_msr_read_intercept(unsigned int msr, > uint64_t *msr_content) > __vmread(GUEST_IA32_DEBUGCTL, msr_content); > break; > case IA32_FEATURE_CONTROL_MSR: > - case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_TRUE_ENTRY_CTLS: > + case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC: > if ( !nvmx_msr_read_intercept(msr, msr_content) ) > goto gp_fault; > break; ... retaining this code structure makes it likely that some future addition will lead to the same problem again. I think there should be something like MSR_IA32_VMX_LAST added to msr-index.h, and get used here instead. Suitably placed it would make pretty obvious to someone adding a new MSR there that this value also needs updating. Or alternatively: Is there an architectural upper bound to the VMX MSR range? If so, we could widen the set to the full range in one go. VMX maintainers - I'd appreciate if you could take care of this in one way or another. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
