Re: [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch

Nick Piggin
2003-09-30T08:01:38Z

Jamie Lokier wrote:

>This builds upon Andi Kleen's excellent patch for the AMD prefetch bug
>workaround. It is applies to 2.6.0-test6.
>
>There are four changes on top of Andi's recent patch:
>
> 1. The workaround code is only included when compiling a kernel
> optimised for AMD processors with the bug. For kernels optimised
> for a different processor, there is no code size overhead.
>
> This will make some people happier.
>
> It will make some people unhappier, because it means a generic
> kernel on an AMD will run fine, but won't fixup _userspace_
> prefetch faults. More on this below.
>
> 2. Nevertheless, when a kernel _not_ optimised for those AMD processors
> is run on one, the "alternative" mechanism now correctly replaces
> prefetch instructions with nops.
>
> 3. The is_prefetch() instruction decoder now handles all cases of
> funny GDT and LDT segments, checks limits and so on. As far as I
> can see, there are no further bugs or flaws in that part.
>
> 4. A consequence of the is_prefetch() change is that, despite the
> longer C code (rarely used code, for segments), is_prefetch()
> should run marginally faster now because the access_ok() calls are
> not required. They're subsumed into the segment limit
> calculation.
>
>Like Andi's patch, this removes 10k or so from current x86 kernels by
>removing the silly conditional from the prefetch() function.
>
>Controversial point coming up!
>

It sounds good Jamie, but could you possibly compile it in
unconditionally? Otherwise it introduces yet another caveat to the CPU
selection / build system. This can be addressed seperately.

I don't think anyone advocates attempting to handle this nicely with the
current CPU selection system, nor were they targeting this patch in
particular. It just kicked off a discussion about the shortfalls of the
selection system.