From: David Woodhouse dwmw@amazon.co.uk
commit def9331a12977770cc6132d79f8e6565871e8e38 upstream
When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus.
This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window has enlarged a little bit by using setup_clear_cpu_cap() instead of the hypervisor's set_cpu_features callback. It seems this larger window now makes it rather easy to hit the problem.
The proper solution is to never set the bit in case of Xen.
Signed-off-by: Juergen Gross jgross@suse.com Reviewed-by: Boris Ostrovsky boris.ostrovsky@oracle.com Acked-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Juergen Gross jgross@suse.com Signed-off-by: David Woodhouse dwmw@amazon.co.uk Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Srivatsa S. Bhat srivatsa@csail.mit.edu Reviewed-by: Matt Helsley (VMware) matt.helsley@gmail.com Reviewed-by: Alexey Makhalov amakhalov@vmware.com Reviewed-by: Bo Gan ganb@vmware.com ---
arch/x86/kernel/cpu/amd.c | 5 +++-- arch/x86/xen/enlighten.c | 4 +--- 2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index f4fb8f5..9b29414 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -791,8 +791,9 @@ static void init_amd(struct cpuinfo_x86 *c) if (cpu_has(c, X86_FEATURE_3DNOW) || cpu_has(c, X86_FEATURE_LM)) set_cpu_cap(c, X86_FEATURE_3DNOWPREFETCH);
- /* AMD CPUs don't reset SS attributes on SYSRET */ - set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS); + /* AMD CPUs don't reset SS attributes on SYSRET, Xen does. */ + if (!cpu_has(c, X86_FEATURE_XENPV)) + set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS); }
#ifdef CONFIG_X86_32 diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 2d7ab4e..82fd84d 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -462,10 +462,8 @@ static void __init xen_init_cpuid_mask(void)
static void __init xen_init_capabilities(void) { - if (xen_pv_domain()) { - setup_clear_cpu_cap(X86_BUG_SYSRET_SS_ATTRS); + if (xen_pv_domain()) setup_force_cpu_cap(X86_FEATURE_XENPV); - } }
static void xen_set_debugreg(int reg, unsigned long val)
On 14/07/18 11:33, Srivatsa S. Bhat wrote:
From: David Woodhouse dwmw@amazon.co.uk
commit def9331a12977770cc6132d79f8e6565871e8e38 upstream
When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus.
This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window has enlarged a little bit by using setup_clear_cpu_cap() instead of the hypervisor's set_cpu_features callback. It seems this larger window now makes it rather easy to hit the problem.
The proper solution is to never set the bit in case of Xen.
Signed-off-by: Juergen Gross jgross@suse.com Reviewed-by: Boris Ostrovsky boris.ostrovsky@oracle.com Acked-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Juergen Gross jgross@suse.com Signed-off-by: David Woodhouse dwmw@amazon.co.uk Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Srivatsa S. Bhat srivatsa@csail.mit.edu Reviewed-by: Matt Helsley (VMware) matt.helsley@gmail.com Reviewed-by: Alexey Makhalov amakhalov@vmware.com Reviewed-by: Bo Gan ganb@vmware.com
I believe you'll need upstream commit 60d3450167433f2d099ce2869dc52dd9e7dc9b29 ("x86/cpu: Re-apply forced caps every time CPU caps are re-read") for this patch to work as intended.
It was necessary for 4.9, at least.
Juergen
On 7/14/18 7:15 AM, Juergen Gross wrote:
On 14/07/18 11:33, Srivatsa S. Bhat wrote:
From: David Woodhouse dwmw@amazon.co.uk
commit def9331a12977770cc6132d79f8e6565871e8e38 upstream
When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus.
This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window has enlarged a little bit by using setup_clear_cpu_cap() instead of the hypervisor's set_cpu_features callback. It seems this larger window now makes it rather easy to hit the problem.
The proper solution is to never set the bit in case of Xen.
Signed-off-by: Juergen Gross jgross@suse.com Reviewed-by: Boris Ostrovsky boris.ostrovsky@oracle.com Acked-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Juergen Gross jgross@suse.com Signed-off-by: David Woodhouse dwmw@amazon.co.uk Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Srivatsa S. Bhat srivatsa@csail.mit.edu Reviewed-by: Matt Helsley (VMware) matt.helsley@gmail.com Reviewed-by: Alexey Makhalov amakhalov@vmware.com Reviewed-by: Bo Gan ganb@vmware.com
I believe you'll need upstream commit 60d3450167433f2d099ce2869dc52dd9e7dc9b29 ("x86/cpu: Re-apply forced caps every time CPU caps are re-read") for this patch to work as intended.
It was necessary for 4.9, at least.
Ah, I see. Thank you for letting me know, Juergen! Looking at 4.9.112, I see that in addition to the patch you mentioned above, we should also backport this patch to 4.4: upstream commit 74899d92e66663dc7671a x6/xen: Add call of speculative_store_bypass_ht_init() to PV paths
The 4.9 backports of these patches apply cleanly to 4.4 as well, but I have attached them anyway with this mail. Greg, could you consider queuing these 2 patches for 4.4 at the end of this patch series?
1. x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths 2. x86/cpu: Re-apply forced caps every time CPU caps are re-read
Thank you!
Regards, Srivatsa VMware Photon OS
linux-stable-mirror@lists.linaro.org