Messages in this thread |  | | Date | Wed, 6 May 2026 22:52:01 +0200 | | From | "Ahmed S. Darwish" <> | | Subject | 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
|  |