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

[Ahmed S. Darwish]

Hi Christian,

On Tue, 05 May 2026, Christian Ludloff wrote:
>
> When Ahmed published, I added them like this:
>
>   https://www.sandpile.org/x86/cpuid.htm#leaf_4C78_0001h
>   https://www.sandpile.org/x86/cpuid.htm#leaf_4C78_0002h
>
> That is, list which Linux word goes where, but not the bits:
> for those, simply have a pointer to code (the "golden ref").
>
> I did suggest two small improvements to Ahmed in private.
>
> First, 4C78_0000 EAX should report the max 4C78 leaf, in
> case there is future expansion. (CPUID does always grow.)
>

Yes, this will be done.

> 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">
    <eax>
      <bit0  len="16"  id="max_subleaf"    desc="Max valid subleaf" />
      <!-- Bits 17:31 reserved -->
    </eax>
    ...
  </subleaf>
</leaf>

since "2^{32} - 1" is too much subleaves anyway, and each mapped
X86_FEATURE word still need a whole register by definition.

I'm not sure if this will have any practical usage right now, but some
future debugfs dumping code might indeed use it.  It will not harm.

Thanks,
Ahmed