[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aB3Jfta9e9fdqZFs@lx-t490>
Date: Fri, 9 May 2025 11:23:10 +0200
From: "Ahmed S. Darwish (dev)" <darwi.dev@...heline.de>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: "Ahmed S. Darwish" <darwi@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
John Ogness <john.ogness@...utronix.de>, x86@...nel.org,
x86-cpuid@...ts.linux.dev, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 02/26] x86/cpu: Sanitize CPUID(0x80000000) output
Hi,
On Wed, 07 May 2025, Andrew Cooper wrote:
>
> On 06/05/2025 6:04 am, Ahmed S. Darwish wrote:
> >
> > CPUID(0x80000000).EAX returns the max extended CPUID leaf available. On
> > x86-32 machines
>
> How certain are you that it's all 32bit CPUs? AIUI, it's an Intel
> specific behaviour, not shared by other x86 vendors of the same era.
>
Sorry, I missed responding to this earlier.
You're correct. I indeed assumed that for all invalid CPUID queries, the
CPU repeats the output of the last valid standard leaf on /all/ x86
machines — thus CPUID(0x80000000) behaves this way also on all x86-32
machines lacking an extended range.
I've done a quick check on some Intel vs. AMD machines, and indeed, this
is Intel-specific. AMD machines just return all-zero instead.
(The patch content is still valid, and I guess that's what HPA was just
hinting at further down the thread.)
Thanks!
~ Ahmed
Powered by blists - more mailing lists