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

[Borislav Petkov]

On Mon, Mar 30, 2026 at 08:29:24PM +0200, Ahmed S. Darwish wrote:
> 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.

Well, since the goal is to have *all* CPUID leaves available to the kernel,
then we *technically* don't need the synthetic ones anymore with the exception
of a handful ones which we defined for ourselves, like X86_FEATURE_ALWAYS, for
example.

But *all* synthetic bits which have correspondence to real CPUID leaves - and
they're synthetic because we wanted to save space... i.e., all those bits in
arch/x86/kernel/cpu/scattered.c, they don't need synthetic flags anymore
because the corresponding full leafs (damn spelling of Blätter eh!) are there.

Then, I'm thinking, we can reorder all the remaining really-synthetic ones
into the unique 4-byte entries and then not even expose them in any db and not
make them available in anything because we will have to cast them in stone
then.

But we don't have to - they're kernel-only and no one needs to know which bits
they occupy.

Something to that effect I'd say...

But we'll get to it eventually.

Thx.

-- 
Regards/Gruss,
    Boris.

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