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. > > 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? > > Thanks, > > ~Andrew > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
