Hi,
In commit a930dc4543a2 ("x86/asm: Cleanup prefetch primitives"), a chunk
of code was added:
/* 3DNow or LM implies PREFETCHW */
if (!cpu_has(c, X86_FEATURE_3DNOWPREFETCH))
if (cpu_has(c, X86_FEATURE_3DNOW) || cpu_has(c, X86_FEATURE_LM))
set_cpu_cap(c, X86_FEATURE_3DNOWPREFETCH);
But Glibc does not contain a similar logic in the CPU feature detection
code, causing a test failure on old CPUs
(https://sourceware.org/bugzilla/show_bug.cgi?id=30328).
I intend to implement the same logic for Glibc. I can understand "3DNow
implies PREFETCHW", but is there a bibliographical reference about "LM
implies PREFETCHW" so I can convince the Glibc maintainers for the
change?
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
On Wed, 2023-06-21 at 14:57 +0200, Borislav Petkov wrote:
> On Wed, Jun 21, 2023 at 08:04:39PM +0800, Xi Ruoyao wrote:
> > Hmm, while it's true for AMD, the Intel SDM claims otherwise. It
> > says
> > prefetchw is only (really) supported with "Intel® Core™ M processor
> > family; 5th Generation Intel® Core™ processor family, Intel Atom
> > processor based on Silvermont microarchitecture" or later. On the
> > earlier Intel CPUs supporting LM, the prefetchw instruction is
> > treated
> > as NOP.
>
> And this is a problem because?
I think it's not an issue in the kernel itself, but announcing
3dnowprefetch in /proc/cpuinfo for an old Intel CPU w/o real prefetchw
implementation seems problematic (to me).
>
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
On Wed, 2023-06-21 at 15:09 +0200, Borislav Petkov wrote:
> On Wed, Jun 21, 2023 at 09:06:51PM +0800, Xi Ruoyao wrote:
> > I think it's not an issue in the kernel itself, but announcing
> > 3dnowprefetch in /proc/cpuinfo for an old Intel CPU w/o real prefetchw
> > implementation seems problematic (to me).
>
> And this is a problem because?
If a code generator parses /proc/cpuinfo for CPU capabilities, it may
generates a no-op prefetchw instead of prefetcht0 as a fallback.
>
> Think practically.
>
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
On Wed, Jun 21, 2023 at 09:06:51PM +0800, Xi Ruoyao wrote:
> I think it's not an issue in the kernel itself, but announcing
> 3dnowprefetch in /proc/cpuinfo for an old Intel CPU w/o real prefetchw
> implementation seems problematic (to me).
And this is a problem because?
Think practically.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Jun 21, 2023 at 09:47:36PM +0800, Xi Ruoyao wrote:
> Oh s**t, I'm completely stupid :(.
No worries, happens to the best of us.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, 2023-06-21 at 15:46 +0200, Borislav Petkov wrote:
> On Wed, Jun 21, 2023 at 09:19:34PM +0800, Xi Ruoyao wrote:
> > On Wed, 2023-06-21 at 15:09 +0200, Borislav Petkov wrote:
> > > On Wed, Jun 21, 2023 at 09:06:51PM +0800, Xi Ruoyao wrote:
> > > > I think it's not an issue in the kernel itself, but announcing
> > > > 3dnowprefetch in /proc/cpuinfo for an old Intel CPU w/o real
> > > > prefetchw
> > > > implementation seems problematic (to me).
> > >
> > > And this is a problem because?
> >
> > If a code generator parses /proc/cpuinfo for CPU capabilities, it
> > may
> > generates a no-op prefetchw instead of prefetcht0 as a fallback.
>
> Err, go back.
>
> That code snippet you pasted, did you see where that comes from?
>
> A function called init_amd().
>
> Now, is Intel hardware and SDM PREFETCHW text at all relevant here?
Oh s**t, I'm completely stupid :(.
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
On Wed, Jun 21, 2023 at 09:19:34PM +0800, Xi Ruoyao wrote:
> On Wed, 2023-06-21 at 15:09 +0200, Borislav Petkov wrote:
> > On Wed, Jun 21, 2023 at 09:06:51PM +0800, Xi Ruoyao wrote:
> > > I think it's not an issue in the kernel itself, but announcing
> > > 3dnowprefetch in /proc/cpuinfo for an old Intel CPU w/o real prefetchw
> > > implementation seems problematic (to me).
> >
> > And this is a problem because?
>
> If a code generator parses /proc/cpuinfo for CPU capabilities, it may
> generates a no-op prefetchw instead of prefetcht0 as a fallback.
Err, go back.
That code snippet you pasted, did you see where that comes from?
A function called init_amd().
Now, is Intel hardware and SDM PREFETCHW text at all relevant here?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette