Re: [PATCH v6 00/90] x86: Introduce a centralized CPUID data model

[H. Peter Anvin]

On May 6, 2026 1:50:49 AM PDT, Borislav Petkov <bp@xxxxxxxxx> wrote:
>On Tue, May 05, 2026 at 12:11:50PM -0700, Christian Ludloff wrote:
>> First, 4C78_0000 EAX should report the max 4C78 leaf, in
>> case there is future expansion. (CPUID does always grow.)
>
>Makes sense to me. That'll tell people up to where we have those defined.
>
>> Second, the number of words reported in 0001h and 0002h
>> should be enumerated, in case the list grows, and so that a
>> program can tell between all-zero and not-present. (ECX>0
>> sub leaves, basically.)
>
>That's good point. So we have now:
>
>words 3, 7, 8, 11, 17, 21
>
>which are Linux-defined. You've mapped them to E[ABCD]X regs. Sure.
>
>We could define subleafs and keep the main function number 4C78_0001 same.
>Sure.
>
>And 0002 is for Linux bug flags then.
>
>That keeps the feature flags where they belong: word 1 is for Linux synthetic
>feature bits and word 2 is for Linux bug flags.  Makes sense.
>
>> Since 0001h has already used up all four registers, it can't
>> report a max sub leaf in EAX – so maybe e.g. 0000h EBX
>> has to do the job instead: it could do e.g. two byte fields, to
>> report the number of words instead, i.e. 0000h BL => 0001h
>> words, and 0001h BH => 0002h words. (Or wider fields... if
>> you expect more future growth for words.)
>
>Do we care?
>
>Those leafs are purely for documentation and no CPUID execution would ever
>return them... (famous last words :)).
>
>> That said, it would be good to get the initial set of commits
>> done so that db updates can start to flow in, to catch up...
>
>Yah, that's why we're talking about them now, before stuff is cast in stone.
>
>I didn't even know you've documented them on sandpile.org before yesterday and
>was under the assumption that no one cares about those leafs outside of the
>kernel. As it should be.
>
>Goes to show once again how we should be very very careful what we're
>exporting outside of the kernel.
>
>Thx.
>

Sadly, not true; modutila at least does use these numbers due to the brain damaged way that cpu feature modprobe strings was done.