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

Hi Boris,

On Fri, 27 Mar 2026, Borislav Petkov wrote:
>
> Hmm, this makes me wonder: we have cases where we take a x86_capability
> element which mirrors a real CPUID reg and then turn it into a synthetic
> word because we end up using only a handful of the real bits and there's
> no need to have almost unused word.
>
> Example:
>
> ddde4abaa0ec ("x86/cpufeatures: Make X86_FEATURE leaf 17 Linux-specific")
>
> I guess I'll see what happens when I reach the end of the patchset - I'm
> just pointing this out now, before I forget so that we don't shoot
> ourselves in the foot ABI-wise and for no good reason.
>

That commit got my attention indeed, and it is referenced below:

  https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v3.0/db/xml/leaf_4c780001.xml#L360

There is an important difference with this series though: all hardware
backed X86_FEATURE words do not consume extra space.  They are redirected,
at compile-time, to their respective entries in the CPUID tables.

It is the synthetic X86_FEATURE words which now consume extra space, as a
unique 4-byte entry in the CPUID tables is required for them.

Now that I'm thinking deeper about this, I guess I should revert that
commit above at this point in the patch queue:

    76  x86/microcode: Allocate cpuinfo_x86 snapshots on the heap
==> NN  Revert "x86/cpufeatures: Make X86_FEATURE leaf 17 Linux-specific"
    77  x86/cpuid: Parse leaves backing X86_FEATURE words
    78  x86/cpuid: Parse Linux synthetic CPUID leaves

Then we let X86_FEATURE word 17 be redirected to CPUID(0x80000007).EBX, as
it was before, and save the CPUID table 4-byte entry for a future synthetic
word.  I'll have to update the XML accordingly, but it's no big deal.

Thanks,
Ahmed