[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] X86: generic MSRs save/restore
On 13/12/2013 09:47, Jan Beulich wrote: >>>> On 13.12.13 at 08:57, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote: >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -580,6 +580,50 @@ static int vmx_load_vmcs_ctxt(struct vcp >> return 0; >> } >> >> +static unsigned int __init vmx_init_msr(void) >> +{ >> + return !!cpu_has_mpx; >> +} >> + >> +static void vmx_save_msr(struct vcpu *v, struct hvm_msr *ctxt) >> +{ >> + vmx_vmcs_enter(v); >> + >> + if ( cpu_has_mpx ) >> + { >> + __vmread(GUEST_BNDCFGS, &ctxt->msr[ctxt->count].val); >> + if ( ctxt->msr[ctxt->count].val ) >> >> >> Isn't it better to remove if()? > Definitely not: That way, if the hardware support MPX but the > guest never used it, restoring the guest on an MPX-incapable > host will be possible. And when the MSR is zero, restoring on an > MPX-capable host will be correct too, as the respective VMCS > field starts out zeroed. > > Jan > Furthermore, this looks as if is heading straight for an ABI breakage. What guarantee is that that the MSRs shall aways be saved and restored in this specific order forever more in the future? I think ctxt->count needs to be replaced with an ABI constant. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |