Re: [PATCH v2 19/20] tools/x86/kcpuid: Update bitfields to x86-cpuid-db v2.3

["Ahmed S. Darwish" <darwi@linutronix.de>]

Hi,

On Wed, 12 Mar 2025, H. Peter Anvin wrote:
>
> On Wed, 12 Mar 2025, "Ahmed S. Darwish" wrote:
> >
> > Update kcpuid's CSV file to version 2.3, as generated by x86-cpuid-db.
> >
> > Summary of the v2.3 changes:
> >
> > * Per H. Peter Anvin's feedback, leaf 0x3 is not unique to Transmeta as
> >   the CSV file earlier claimed.  Since leaf 0x3's format differs between
> >   Intel and Transmeta, and the project does not yet support having the
> >   same CPUID bitfield with varying interpretations across vendors, leaf
> >   0x3 is removed for now.  Given that Intel discontinued support for PSN
> >   from Pentium 4 onward, and Linux force disables it on early boot for
> >   privacy concerns, this should have minimal impact.
> >
> > * Leaf 0x80000021: Make bitfield IDs and descriptions coherent with each
> >   other.  Remove "_support" from bitfield IDs, as no other leaf has such
> >   convention.
> >
> > Reported-by: "H. Peter Anvin" <hpa@zytor.com>
> > Closes: https://lkml.kernel.org/r/C7684E03-36E0-4D58-B6F0-78F4DB82D737@zytor.com
> > Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
> > Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v2.3/CHANGELOG.rst
> > ---
>
> As I said, you can simply treat leaf 3 as raw 128-bit hexadecimal
> number; there really isn't a need to "interpret" it since the only
> meaningful use of it is as a unique identifier combined with
> vendor-FMS.

Yes, but this would introduce special-case leaf handing in kcpuid.
So far, the kcpuid code is "dumb".  It just parses the CPUID bitfields
according to what's in the CSV file, with no intrinsic knowledge of any
certain leaf by the C code.

This is why, for example, kcpuid does not print CPU vendor strings in
human readable form.  It just dumps whatever is there in the various
leaves bitfields:

    $ kcpuid --all -l 0
        max_std_leaf        	: 0x16
        cpu_vendorid_0      	: 0x756e6547
        cpu_vendorid_2      	: 0x6c65746e
        cpu_vendorid_1      	: 0x49656e69

    $ kcpuid --all --detail -l 0
    CPUID_0x0_EAX[0x0]:
	max_std_leaf        	: 0x16      	- Highest standard CPUID leaf supported
    CPUID_0x0_EBX[0x0]:
	cpu_vendorid_0      	: 0x756e6547	- CPU vendor ID string bytes 0 - 3
    CPUID_0x0_ECX[0x0]:
	cpu_vendorid_2      	: 0x6c65746e	- CPU vendor ID string bytes 8 - 11
    CPUID_0x0_EDX[0x0]:
	cpu_vendorid_1      	: 0x49656e69	- CPU vendor ID string bytes 4 - 7

We can extend kcpuid to handle a special case for the PSN, but if we
gonna do that, then it would be much better to start that with CPUID
leaves that actually matter: CPU vendor strings, leaf 0x2 1-byte
descriptor semantics, etc., etc.

Given all that, can we please move on regarding this leaf 0x3PSN thing?
IMHO, there's no reason to block the series because of that :(

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH