Re: [Xen-devel] MSR load lists on Harpertown
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 Just to follow up on this thread (seeing as it is referenced in several places), it turns out that I need a dunce cap. Igor discovered that this is caused by a software bug introduced by me. The proposed fix is https://lists.xenproject.org/archives/html/xen-devel/2019-04/msg00390.html The load lists appear to function just fine, even for MSR_EFER.SCE, when Xen programs the VMCS correctly. Sorry for all the noise. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] MSR load lists on Harpertown
On 18/12/2018 11:37, Jan Beulich wrote: On 18.12.18 at 10:56, wrote: >> On 18/12/2018 02:17, Tian, Kevin wrote: From: Andrew Cooper [mailto:andrew.coop...@citrix.com] Sent: Monday, December 17, 2018 10:21 PM 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 >>> Just confirmed that there is no erratum which could explain above >>> behavior. >>> >>> I see several options here: >>> >>> a) load guest EFER in Xen context, just before vmentry. make sure no stack >>> access between load and VM enter. but it sounds messy to add such sku >>> specific workaround in that common path (especially just for an old one); >>> >>> b) leave guest following Xen NXE setting on Harpertown. doing so bears >>> with limitation as what fd32dcfe tries to fix, but it's better than syscall >>> error in 64bit guest. also not clean since some ad-hoc logic that is removed >>> by fd32dcfe may have to be added back; >>> >>> c) leave above issue unfixed. Harpertown is pretty old... >>> >>> d) more debug whether above is caused by other software bug >> Option a) is not possible. While we could in principle turn the line of >> pop gpr's into movs and avoid the stack accesses, > How would this avoid stack accesses? Very good point. I blame a complete lack of coffee while writing this email. The only option to make this work would be to map the stack as executable, and we most certainly aren't doing that as a workaround. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] MSR load lists on Harpertown
>>> On 18.12.18 at 10:56, wrote: > On 18/12/2018 02:17, Tian, Kevin wrote: >>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >>> Sent: Monday, December 17, 2018 10:21 PM >>> >>> 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 >>> >> Just confirmed that there is no erratum which could explain above >> behavior. >> >> I see several options here: >> >> a) load guest EFER in Xen context, just before vmentry. make sure no stack >> access between load and VM enter. but it sounds messy to add such sku >> specific workaround in that common path (especially just for an old one); >> >> b) leave guest following Xen NXE setting on Harpertown. doing so bears >> with limitation as what fd32dcfe tries to fix, but it's better than syscall >> error in 64bit guest. also not clean since some ad-hoc logic that is removed >> by fd32dcfe may have to be added back; >> >> c) leave above issue unfixed. Harpertown is pretty old... >> >> d) more debug whether above is caused by other software bug > > Option a) is not possible. While we could in principle turn the line of > pop gpr's into movs and avoid the stack accesses, How would this avoid stack accesses? > we will triple fault if an NMI/#MC hits. > > As for option d), I'm quite certain at this point that it is a > hardware/microcode issue, rather than a software issue. > > I'd prefer to leave Harpertown cores working than simply dismissing them > at this point, because they are still useful for compatibility testing. > TBH, I was expecting option b) to be the outcome. So did I, with ... > I don't suppose there is any chance of this being published as an > erratum which I can reference in the source code? ... such a reference. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] MSR load lists on Harpertown
On 18/12/2018 02:17, Tian, Kevin wrote: >> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] >> Sent: Monday, December 17, 2018 10:21 PM >> >> 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 >> > Just confirmed that there is no erratum which could explain above > behavior. > > I see several options here: > > a) load guest EFER in Xen context, just before vmentry. make sure no stack > access between load and VM enter. but it sounds messy to add such sku > specific workaround in that common path (especially just for an old one); > > b) leave guest following Xen NXE setting on Harpertown. doing so bears > with limitation as what fd32dcfe tries to fix, but it's better than syscall > error in 64bit guest. also not clean since some ad-hoc logic that is removed > by fd32dcfe may have to be added back; > > c) leave above issue unfixed. Harpertown is pretty old... > > d) more debug whether above is caused by other software bug Option a) is not possible. While we could in principle turn the line of pop gpr's into movs and avoid the stack accesses, we will triple fault if an NMI/#MC hits. As for option d), I'm quite certain at this point that it is a hardware/microcode issue, rather than a software issue. I'd prefer to leave Harpertown cores working than simply dismissing them at this point, because they are still useful for compatibility testing. TBH, I was expecting option b) to be the outcome. I don't suppose there is any chance of this being published as an erratum which I can reference in the source code? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] MSR load lists on Harpertown
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, December 17, 2018 10:21 PM > > 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 > Just confirmed that there is no erratum which could explain above behavior. I see several options here: a) load guest EFER in Xen context, just before vmentry. make sure no stack access between load and VM enter. but it sounds messy to add such sku specific workaround in that common path (especially just for an old one); b) leave guest following Xen NXE setting on Harpertown. doing so bears with limitation as what fd32dcfe tries to fix, but it's better than syscall error in 64bit guest. also not clean since some ad-hoc logic that is removed by fd32dcfe may have to be added back; c) leave above issue unfixed. Harpertown is pretty old... d) more debug whether above is caused by other software bug Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] MSR load lists on Harpertown
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
Re: [Xen-devel] MSR load lists on Harpertown
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. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] MSR load lists on Harpertown
> From: Tian, Kevin > Sent: Tuesday, December 11, 2018 3:10 PM > > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > > 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 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] MSR load lists on Harpertown
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > 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? > > > > 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. btw did you try upgrading to a newer microcode? Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] MSR load lists on Harpertown
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
Re: [Xen-devel] MSR load lists on Harpertown
On 05/11/18 16:25, Ian Jackson wrote:
> Andrew Cooper writes ("[Xen-devel] MSR load lists on Harpertown"):
>> I realise this is an old CPU, but I've I've encountered a weird failure
>> on it.
> ...
>> 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?
> ISTM that Xen should run on these old CPUs and also that it should
> work, ideally, even if the microcode is buggy.
>
> So presumaly the right answer is to simply disable NX for the guest
> completely ?
As you've observed, when SCE doesn't work, everything is fully hosed.
However, disabling NX on that CPU won't fix the problem, because the
problem appears to be using the MSR load list.
Without a microcode fix (if indeed this is a microcode issue, but given
how much of vmentry is, I'd be surprised if it is something else), the
only fix I can see is to effectively revert the change to use MSR load
lists.
However, I really don't want to do this unilaterally, because it will
break NX handling on all Intel hardware, and reintroduce a wart into the
context switch code which I thought I'd excised properly.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] MSR load lists on Harpertown
Andrew Cooper writes ("[Xen-devel] MSR load lists on Harpertown"):
> I realise this is an old CPU, but I've I've encountered a weird failure
> on it.
...
> 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?
ISTM that Xen should run on these old CPUs and also that it should
work, ideally, even if the microcode is buggy.
So presumaly the right answer is to simply disable NX for the guest
completely ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
