From: Andi Kleen <[email protected]>
The AMD K6 errata check relies on timing a indirect call.
But the way it was written it could be optimized to a direct call.
Force gcc to actually do a indirect call and not just
constant resolve the target address.
Found during code review, no runtime testing due to lack
of hardware.
v2: More description
Signed-off-by: Andi Kleen <[email protected]>
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 4a549db..11ea6f6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -115,7 +115,7 @@ static void __cpuinit init_amd_k6(struct cpuinfo_x86 *c)
*/
n = K6_BUG_LOOP;
- f_vide = vide;
+ asm("" : "=g" (f_vide) : "0" (vide));
rdtscl(d);
while (n--)
f_vide();
On 04/21/2013 09:49 AM, Andi Kleen wrote:
> From: Andi Kleen <[email protected]>
>
> The AMD K6 errata check relies on timing a indirect call.
> But the way it was written it could be optimized to a direct call.
> Force gcc to actually do a indirect call and not just
> constant resolve the target address.
>
> Found during code review, no runtime testing due to lack
> of hardware.
Maybe it would be even better to just code the indirect call instruction
in assembly?
Something like:
asm volatile("call *%0"
: : "r" (vide)
: "eax", "ecx", "edx");
Gotta love the metal mask(?) fix without bumping the stepping number...
-hpa
> Maybe it would be even better to just code the indirect call instruction
> in assembly?
I only have the simple low risk fix to offer. If you want something
gold plated you have to do/test it yourself.
-Andi
On Sun, Apr 21, 2013 at 10:06:58AM -0700, H. Peter Anvin wrote:
> On 04/21/2013 09:49 AM, Andi Kleen wrote:
> > From: Andi Kleen <[email protected]>
> >
> > The AMD K6 errata check relies on timing a indirect call.
> > But the way it was written it could be optimized to a direct call.
> > Force gcc to actually do a indirect call and not just
> > constant resolve the target address.
> >
> > Found during code review, no runtime testing due to lack
> > of hardware.
>
> Maybe it would be even better to just code the indirect call instruction
> in assembly?
>
> Something like:
>
> asm volatile("call *%0"
> : : "r" (vide)
> : "eax", "ecx", "edx");
>
> Gotta love the metal mask(?) fix without bumping the stepping number...
They fixed it in the next revision:
"Resolution Status. This erratum is corrected in the C stepping of the
AMD-K6 processor."
On page 12 here http://www.datasheetcatalog.org/datasheet/AdvancedMicroDevices/mXwsxv.pdf
But it looks some revBs got fixed too reportedly: "... before B
9730xxxx...". Who knows.
Btw, I can't help but cringe everytime I see the wording "...
instruction is speculatively executed... " in an erratum :-).
So the poor K6 had some issues with SMC, that's sad.
But I have hard time understanding what that test with the 10^6 loop
iterations is supposed to achieve. And what makes sure that the RDTSCs
don't get reordered? Or maybe K6 wasn't reordering that aggressively...
Erratum says "unpredictable system behavior" but it seems it wasn't that
unpredictable after all - otherwise the fix would've been "HLT" right
then and there. :)
Oh well.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On 04/21/2013 10:44 AM, Borislav Petkov wrote:
>
> But I have hard time understanding what that test with the 10^6 loop
> iterations is supposed to achieve. And what makes sure that the RDTSCs
> don't get reordered? Or maybe K6 wasn't reordering that aggressively...
>
> Erratum says "unpredictable system behavior" but it seems it wasn't that
> unpredictable after all - otherwise the fix would've been "HLT" right
> then and there. :)
>
Looks like it is just trying to sense the bug... but then it doesn't
actually do anything about it. At least it should taint the kernel.
-hpa
On Sun, Apr 21, 2013 at 03:35:41PM -0700, H. Peter Anvin wrote:
> Looks like it is just trying to sense the bug... but then it doesn't
> actually do anything about it. At least it should taint the kernel.
Yeah, I was thinking of asking my old contacts about it but it is simply
not worth it. Those CPUs are on their way to the museum if they're not
there already.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
Hi,
>Yeah, I was thinking of asking my old contacts about it but it is simply
>not worth it. Those CPUs are on their way to the museum if they're not
>there already.
I have a perfectly running K6 system (the legendary K6-III I believe),
though I am about to have it taken to recycling.
If you want anything tested, I can still do it this week.
Regards,
Wolfram.
On Monday 22 April 2013, Wolfram Gloger wrote:
> Hi,
>
> >Yeah, I was thinking of asking my old contacts about it but it is simply
> >not worth it. Those CPUs are on their way to the museum if they're not
> >there already.
>
> I have a perfectly running K6 system (the legendary K6-III I believe),
> though I am about to have it taken to recycling.
> If you want anything tested, I can still do it this week.
This bug was present on the original K6 only, not K6-2 or K6-3. I think that I
have a K6 somewhere but I doubt that it's one of the early buggy ones.
Here are the details: http://membres.multimania.fr/poulot/k6bug_faq.html
--
Ondrej Zary