On 20.10.2023 15:17, Greg Kroah-Hartman wrote:
On Fri, Oct 20, 2023 at 11:41:13AM +0200, Maciej S. Szmigiero wrote:
On 15.03.2023 13:11, Greg Kroah-Hartman wrote:
From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
commit b0563468eeac88ebc70559d52a0b66efc37e4e9d upstream.
AMD Erratum 1386 is summarised as:
XSAVES Instruction May Fail to Save XMM Registers to the Provided
State Save Area
This piece of accidental chronomancy causes the %xmm registers to
occasionally reset back to an older value.
Ignore the XSAVES feature on all AMD Zen1/2 hardware. The XSAVEC
instruction (which works fine) is equivalent on affected parts.
[ bp: Typos, move it into the F17h-specific function. ]
Reported-by: Tavis Ormandy <taviso@xxxxxxxxx>
Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Signed-off-by: Borislav Petkov (AMD) <bp@xxxxxxxxx>
Cc: <stable@xxxxxxxxxx>
Link: https://lore.kernel.org/r/20230307174643.1240184-1-andrew.cooper3@xxxxxxxxxx
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
arch/x86/kernel/cpu/amd.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -205,6 +205,15 @@ static void init_amd_k6(struct cpuinfo_x
return;
}
#endif
+ /*
+ * Work around Erratum 1386. The XSAVES instruction malfunctions in
+ * certain circumstances on Zen1/2 uarch, and not all parts have had
+ * updated microcode at the time of writing (March 2023).
+ *
+ * Affected parts all have no supervisor XSAVE states, meaning that
+ * the XSAVEC instruction (which works fine) is equivalent.
+ */
+ clear_cpu_cap(c, X86_FEATURE_XSAVES);
}
This is essentially a well-intended NOP since K6 well predates XSAVES,
and init_amd_k6() is *not* called for Zen CPUs.
This workaround should have been added to init_amd_zn() function
instead.
4.19 and 4.14 backports of this patch have the same problem.
Ick, good catch! Can you send a set of patches to fix this up?
I can add this to my TODO list, but unfortunately can't promise
a short ETA at this point.
thanks,
greg k-h
Thanks,
Maciej
