On 17/12/2018 13:09, Andrew Cooper wrote: > On 17/12/2018 02:39, Tian, Kevin wrote: >>>>> 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? > Apologies for the delay. I was travelling last week. > > We cannot load the full guest's EFER value in Xen context. If the guest > has NX disabled, the next stack access in Xen will fault because the NX > bit becomes reserved when EFER.NXE is clear. > > As for the more general case of loading the guests EFER value (ignoring > NXE), we already know that works, because it is how Xen functioned for a > decade. > > I see that the latest production microcode on otcshare is slightly newer > than exists in the microcode_ctl package. I'll give it a spin.
The behaviour is still the same, even with the latest microcode: (XEN) microcode: CPU0 updated from revision 0x60f to 0x612, date = 2015-08-02 ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
