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

Hi Boris,

On Tue, 05 May 2026, Borislav Petkov wrote:
>
> Ok, talked it over with tglx - he brought up the argument that actually
> having those flags documented is good for other tools like crash, etc,
> where you want to consult a single db for *all* X86_FEATURE flags in the
> kernel - no matter how they're defined.
>
> So, what we will do is, we'll leave those leafs as is and not touch them.
>
> If we need to add new, solely synthetic bits, we'll add them where
> there's room, document them in the db and that's it. Synthetic bits will
> be add-only and the cpuid-db will collect them.
>
> This way you have a single source for all CPUID info.
>
> The scattered.c thing goes away because we have full CPUID leaf
> representation now.
>
> We only get purely synthetic new additions to the db and we can use the
> Lx namespace for that. I guess that's plenty of room for the foreseeable
> future.
>
> Makes sense?
>

Yes, I think so.

"scattered.c thing goes away" in the sense that:

    No new hardware-backed X86_FEATURE synthetic bit will ever be added to
    the kernel.  Now that a full CPUID table exists, the standard CPUID
    APIs should be used for such cases instead.

Thus, "We only get purely synthetic new additions to the db."

For the /current/ scattered feature bits, the array which maps them to
their hardware backing:

    static const struct cpuid_bit cpuid_bits[] = {
	{ X86_FEATURE_APERFMPERF,	CPUID_ECX,  0, 0x00000006, 0 },
	{ X86_FEATURE_EPB,		CPUID_ECX,  3, 0x00000006, 0 },
	{ ... },
    }

is needed.  The direct CPUID calls at scattered.c will just need to be
converted to their equivalent CPUID APIs though.

(I guess that's what you already meant, but I wanted to be sure.)

Thanks,
Ahmed