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

[Christian Ludloff]

On Wed, May 6, 2026 at 3:18 PM Borislav Petkov <bp@xxxxxxxxx> wrote:
> On Wed, May 06, 2026 at 11:57:20PM +0200, Ahmed S. Darwish wrote:
> > > 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.)
> > >
> > > 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.)
> > >
> >
> > For both CPUID(0x4c780001) and CPUID(0x4c780002), I can still reserve
> > their EAX for that.  Something like:
> >
> > <leaf id="0x4c780001">
> >   <subleaf id="0">
>
> Can we slow down here please?
>
> If we're going to deal with maxleaves, then I'd say that ship has already
> sailed looong time ago.
>
> Because up until now there's no maxleaf for those Linux-defined words. So you
> *still* have to know which kernel you're looking at to know which words are
> defined, and which words are reserved zeros.
>
> The only thing you have is the database we're building here.
>
> And since it'll be append-only for the Linux leaves, if it is not in the
> database, it does not exist.
>
> If you want to use it and decypher feature words, you still need to know which
> kernel we're talking about. Because cpufeatures.h has the number of
> Linux-specific words which this particular kernel knows about.
>
> And if we're going to differentiate between defined and reserved, then we need
> to save the kernel version from which onwards those bits actually have
> a meaning.
>
> And that would be ugly.
>
> So if you see word X, bit Y set, then that is a synthetic word bit and it is
> enabled. If it is not set, it is not present or not enabled but again, without
> kernel version you don't know anyway.

In the end, it is a bit string.

So maybe report the max
bit that is being reported?

And yes, 'version' is hard.

You sort of need the hash
of cpufeatures.h so a pull
of kernel x.y.z plus a mod
around flag or bug words
doesn't just say x.y.z, still.

--
C.