Re: [Xen-devel] MSR load lists on Harpertown

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Tian, Kevin
> Sent: Tuesday, December 11, 2018 3:10 PM
> 
> > From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> > Sent: Tuesday, December 11, 2018 1:13 AM
> >
> > Ping Kevin / Jun.
> >
> > On 16/10/2018 19:54, Andrew Cooper wrote:
> > > Hello,
> > >
> > > I realise this is an old CPU, but I've I've encountered a weird failure
> > > on it.
> > >
> > > Specifically:
> > >
> > > (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 23 (0x17), Stepping 6
> > > (raw 00010676)
> > > [root@harpertown ~]# head /proc/cpuinfo
> > > processor    : 0
> > > vendor_id    : GenuineIntel
> > > cpu family    : 6
> > > model        : 23
> > > model name    : Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz
> > > stepping    : 6
> > > microcode    : 0x60f
> > > cpu MHz        : 2493.756
> > > cache size    : 6144 KB
> > > physical id    : 0
> > >
> > > In Xen, we use an MSR load list to update EFER on vmentry/exit, when
> > > hardware doesn't support the EFER field in the VMCB itself.  This is a
> > > change I made in 4.11 to fix a bug with NX handling on context switching.
> 
> can you point to the commit number of NX fix?

just found it.

commit fd32dcfe4c9a539f8e5d26ff4c5ca50ee54556b2
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue May 23 17:32:30 2017 +0100

    x86/vmx: Don't leak EFER.NXE into guest context

> 
> > >
> > > After some investigation, it turns out that after vmentry, while the
> > > load list has the value 0xd01 (NXE, LMA, LME, SCE), the value loaded
> > > into hardware is 0xd00 (NXE, LMA, LME).
> > >
> > > I.e. when an MSR load list is used for EFER, we resume the guest with
> > > SCE cleared.  This is rather terminal for 64bit guests, as
> > > syscall/sysret instructions take a #UD fault.
> > >
> > > I can't see anything relevant in the Specification Update for this
> > > processor.
> > >
> > > I've confirmed that by not using a load list, the current value in EFER
> > > is preserved once the vmentry is complete, and by disabling the EFER
> > > intercept, I can re-set SCE in non-root context and have syscall/sysret
> > > work correctly.
> > >
> > > However, given this behaviour, I can't think of any way to context
> > > switch NX properly, and leave 64bit guests in a working state.
> > >
> > > Do you have any suggestions?
> > >
> 
> I'm checking internally whether it's a known issue.

from feedbacks that I collected so far, no one is aware of this issue.

> 
> btw did you try upgrading to a newer microcode?
> 

while I'm approaching more channels, does it work by directly
WRMSR to EFER just before VMENTRY for above special case (
thus remove EFER from MSR load/save list), if ucode update
also fails? there is just a small window where NX might be wrong 
setting for Xen, but it might be OK for that carefully-baked code 
snippet?

Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel