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

[Borislav Petkov]

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.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette