On 02/02/17 12:52, Jan Beulich wrote: >>>> On 31.01.17 at 12:20, <[email protected]> wrote: >> --- a/xen/arch/x86/hvm/vmx/vvmx.c >> +++ b/xen/arch/x86/hvm/vmx/vvmx.c >> @@ -264,7 +264,7 @@ u64 get_vvmcs_real(const struct vcpu *v, u32 encoding) >> return virtual_vmcs_vmread(v, encoding); >> } >> >> -void set_vvmcs_virtual(void *vvmcs, u32 vmcs_encoding, u64 val) >> +unsigned long set_vvmcs_virtual(void *vvmcs, u32 vmcs_encoding, u64 val) >> { >> union vmcs_encoding enc; >> u64 *content = (u64 *) vvmcs; >> @@ -298,11 +298,13 @@ void set_vvmcs_virtual(void *vvmcs, u32 vmcs_encoding, >> u64 val) >> } >> >> content[offset] = res; >> + >> + return 0; >> } > Is it reasonable for this to never fail?
No. Fields and values need to be audited against the features offered to the guest in the VT-x MSRs. However, it is not worth trying to fix that now before the MSR levelling work is started, at which point we will have a cpuid_policy-like object to query. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xen.org/xen-devel
