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

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

[Maciej Wieczor-Retman]

On 2026-04-13 at 16:38:31 +0200, Ahmed S. Darwish wrote:
>Hi Maciej,
>
>On Tue, 07 Apr 2026, Maciej Wieczor-Retman wrote:
>>
>> Hi, very cool rework! So far I didn't notice any problems while testing.
>>
>
>Thanks a lot for testing!
>
>I will appreciate then adding a Tested-by tag on v7, where the interesting
>bits will hopefully start to get merged.

Sure, I'll rememeber to retest once v7 is out :)

>>
>> Buy anyway I wanted to ask if you thought about including the cpuid_deps[] or
>> cpuid_dependent_features[] into the new cpuid API ecosystem?
>>
>> Or if not (since this patchset is quite long already :b ), then do you have any
>> idea where best it could fit in? During discussion on [1] you mentioned the
>> feature depenedency should be encoded in x86-cpuid-db. I assume you meant it
>> would need to be first patched into there, then parsed by Kconfig?
>>
>> [1] https://lore.kernel.org/all/acruJf-pyld-fTh1@lx-t490/
>>
>
>Sorry, I'm just back from Easter vacations; that's why I didn't answer your
>question in that other thread.
>
>x86-cpuid-db will encode all the feature dependencies in its XML database.
>Then it can generate all the necessary dependency structures, in a way that
>is easy to parse for all kernel phases; including the kconfig build phase.
>
>Then, what you want to do can be cleanly added on top.
>
>P.S. I'm already removing <asm/cpufeatures.h> in the next iteration, along
>with its ugly "/proc/cpuinfo names inside multi-line C comments" hack.

Cool, thanks for letting me know!

>
>Kind regards,
>Ahmed

-- 
Kind regards
Maciej Wieczór-Retman

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

[Ahmed S. Darwish]

Hi,

On Thu, 07 May 2026, Borislav Petkov wrote:
>
> On Wed, May 06, 2026 at 10:52:01PM +0200, Ahmed S. Darwish wrote:
> > 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.
>
> My assumption is that at the end of the patchset, scattered.c is gone because
> we have *all* hw CPUID functions present.
>

Not in this patchset, but in a follow-up one, yes.

For the scattered.c code to be removed, per-bit mappings to the CPUID
table, for the hardware-backed synthetic feature bits, will need to be
added.

Due to all the code which required per-word access semantics to x86
features, [*] I prioritized finishing the cpuid_word.*() APIs and such word
mappings first.

Thanks,
Ahmed

[*] KVM's reverse feature maps, early 32-bit ASM code, the AWK and shell
    code generation build scripts, early boot feature validation, feature
    naming tables, etc.

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

[Borislav Petkov]

On Wed, May 06, 2026 at 10:52:01PM +0200, Ahmed S. Darwish wrote:
> 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.

My assumption is that at the end of the patchset, scattered.c is gone because
we have *all* hw CPUID functions present.

-- 
Regards/Gruss,
    Boris.

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

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

[Christian Ludloff]

On Wed, May 6, 2026 at 3:18 PM Borislav Petkov <bp@alien8.de> wrote:
> On Wed, May 06, 2026 at 11:57:20PM +0200, Ahmed S. Darwish wrote:
> > > 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">
>
> Can we slow down here please?
>
> If we're going to deal with maxleaves, then I'd say that ship has already
> sailed looong time ago.
>
> Because up until now there's no maxleaf for those Linux-defined words. So you
> *still* have to know which kernel you're looking at to know which words are
> defined, and which words are reserved zeros.
>
> The only thing you have is the database we're building here.
>
> And since it'll be append-only for the Linux leaves, if it is not in the
> database, it does not exist.
>
> If you want to use it and decypher feature words, you still need to know which
> kernel we're talking about. Because cpufeatures.h has the number of
> Linux-specific words which this particular kernel knows about.
>
> And if we're going to differentiate between defined and reserved, then we need
> to save the kernel version from which onwards those bits actually have
> a meaning.
>
> And that would be ugly.
>
> So if you see word X, bit Y set, then that is a synthetic word bit and it is
> enabled. If it is not set, it is not present or not enabled but again, without
> kernel version you don't know anyway.

In the end, it is a bit string.

So maybe report the max
bit that is being reported?

And yes, 'version' is hard.

You sort of need the hash
of cpufeatures.h so a pull
of kernel x.y.z plus a mod
around flag or bug words
doesn't just say x.y.z, still.

--
C.

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

[Borislav Petkov]

On Wed, May 06, 2026 at 11:57:20PM +0200, Ahmed S. Darwish wrote:
> > 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">

Can we slow down here please?

If we're going to deal with maxleaves, then I'd say that ship has already
sailed looong time ago.

Because up until now there's no maxleaf for those Linux-defined words. So you
*still* have to know which kernel you're looking at to know which words are
defined, and which words are reserved zeros.

The only thing you have is the database we're building here.

And since it'll be append-only for the Linux leaves, if it is not in the
database, it does not exist.

If you want to use it and decypher feature words, you still need to know which
kernel we're talking about. Because cpufeatures.h has the number of
Linux-specific words which this particular kernel knows about.

And if we're going to differentiate between defined and reserved, then we need
to save the kernel version from which onwards those bits actually have
a meaning.

And that would be ugly.

So if you see word X, bit Y set, then that is a synthetic word bit and it is
enabled. If it is not set, it is not present or not enabled but again, without
kernel version you don't know anyway.

Thx.

-- 
Regards/Gruss,
    Boris.

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

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

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

[Ahmed S. Darwish]

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

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

[Christian Ludloff]

On Wed, May 6, 2026 at 1:51 AM Borislav Petkov <bp@alien8.de> wrote:
> On Tue, May 05, 2026 at 12:11:50PM -0700, Christian Ludloff wrote:
> > First, 4C78_0000 EAX should report the max 4C78 leaf, in
> > case there is future expansion. (CPUID does always grow.)
>
> Makes sense to me. That'll tell people up to where we have those defined.

Right.

> > 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.)
>
> That's good point. So we have now:
>
> words 3, 7, 8, 11, 17, 21
>
> which are Linux-defined. You've mapped them to E[ABCD]X regs. Sure.

I merely grabbed what Ahmed defined.

> We could define subleafs and keep the main function number 4C78_0001 same.
> Sure.
>
> And 0002 is for Linux bug flags then.
>
> That keeps the feature flags where they belong: word 1 is for Linux synthetic
> feature bits and word 2 is for Linux bug flags.  Makes sense.
>
> > 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.)
>
> Do we care?

Yes.

To tell "reserved – no word here" and "word has all bits 0".

> Those leafs are purely for documentation and no CPUID execution would ever
> return them... (famous last words :)).

Humans love to enumerate.
Humans love to CPUID.
Humans love to printf().

> > That said, it would be good to get the initial set of commits
> > done so that db updates can start to flow in, to catch up...
>
> Yah, that's why we're talking about them now, before stuff is cast in stone.
>
> I didn't even know you've documented them on sandpile.org before yesterday and
> was under the assumption that no one cares about those leafs outside of the
> kernel. As it should be.
>
> Goes to show once again how we should be very very careful what we're
> exporting outside of the kernel.

The Linux-defined bits are useful, for both, flag bits and bug bits.

Because sometimes hardware CPUID failed to allocate any bits.

And because humans love to know if their Linux fixed bug X Y Z.

--
C.

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

[Borislav Petkov]

On Wed, May 06, 2026 at 06:59:12AM -0700, H. Peter Anvin wrote:
> Sadly, not true; modutila at least does use these numbers due to the brain
> damaged way that cpu feature modprobe strings was done.

That damn thing!

---
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Wed May 6 16:43:12 2026 +0200

    x86/cpufeatures: Document that feature numbers can potentially be an ABI
    
    Way too late to change that so document it so that it is written down
    somewhere and not getting forgotten from time to time and the evil
    awakening during development of fancy new things can be spared.
    
    Reported-by: "H. Peter Anvin" <hpa@zytor.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 1d506e5d6f46..5937e2a30da1 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -15,6 +15,10 @@
  *
  * When adding new features here that depend on other features,
  * please update the table in kernel/cpu/cpuid-deps.c as well.
+ *
+ * Note that modutils at least does use these numbers due to the brain-damaged
+ * way that CPU feature modprobe strings was done so the safe assumption is to
+ * think of those as ABI. For that look at do_x86cpu_entry() in file2alias.c.
  */
 
 /* Intel-defined CPU features, CPUID level 0x00000001 (EDX), word 0 */


-- 
Regards/Gruss,
    Boris.

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

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

[H. Peter Anvin]

On May 6, 2026 1:50:49 AM PDT, Borislav Petkov <bp@alien8.de> wrote:
>On Tue, May 05, 2026 at 12:11:50PM -0700, Christian Ludloff wrote:
>> First, 4C78_0000 EAX should report the max 4C78 leaf, in
>> case there is future expansion. (CPUID does always grow.)
>
>Makes sense to me. That'll tell people up to where we have those defined.
>
>> 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.)
>
>That's good point. So we have now:
>
>words 3, 7, 8, 11, 17, 21
>
>which are Linux-defined. You've mapped them to E[ABCD]X regs. Sure.
>
>We could define subleafs and keep the main function number 4C78_0001 same.
>Sure.
>
>And 0002 is for Linux bug flags then.
>
>That keeps the feature flags where they belong: word 1 is for Linux synthetic
>feature bits and word 2 is for Linux bug flags.  Makes sense.
>
>> 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.)
>
>Do we care?
>
>Those leafs are purely for documentation and no CPUID execution would ever
>return them... (famous last words :)).
>
>> That said, it would be good to get the initial set of commits
>> done so that db updates can start to flow in, to catch up...
>
>Yah, that's why we're talking about them now, before stuff is cast in stone.
>
>I didn't even know you've documented them on sandpile.org before yesterday and
>was under the assumption that no one cares about those leafs outside of the
>kernel. As it should be.
>
>Goes to show once again how we should be very very careful what we're
>exporting outside of the kernel.
>
>Thx.
>

Sadly, not true; modutila at least does use these numbers due to the brain damaged way that cpu feature modprobe strings was done.

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

[Borislav Petkov]

On Tue, May 05, 2026 at 12:11:50PM -0700, Christian Ludloff wrote:
> First, 4C78_0000 EAX should report the max 4C78 leaf, in
> case there is future expansion. (CPUID does always grow.)

Makes sense to me. That'll tell people up to where we have those defined.

> 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.)

That's good point. So we have now:

words 3, 7, 8, 11, 17, 21

which are Linux-defined. You've mapped them to E[ABCD]X regs. Sure.

We could define subleafs and keep the main function number 4C78_0001 same.
Sure.

And 0002 is for Linux bug flags then.

That keeps the feature flags where they belong: word 1 is for Linux synthetic
feature bits and word 2 is for Linux bug flags.  Makes sense.

> 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.)

Do we care?

Those leafs are purely for documentation and no CPUID execution would ever
return them... (famous last words :)).

> That said, it would be good to get the initial set of commits
> done so that db updates can start to flow in, to catch up...

Yah, that's why we're talking about them now, before stuff is cast in stone.

I didn't even know you've documented them on sandpile.org before yesterday and
was under the assumption that no one cares about those leafs outside of the
kernel. As it should be.

Goes to show once again how we should be very very careful what we're
exporting outside of the kernel.

Thx.

-- 
Regards/Gruss,
    Boris.

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

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

[Christian Ludloff]

On Tue, May 5, 2026 at 8:13 AM Borislav Petkov <bp@alien8.de> wrote:
> On Tue, May 05, 2026 at 03:33:50PM +0200, Borislav Petkov wrote:
> > On Mon, Apr 27, 2026 at 08:45:23PM +0200, Ahmed S. Darwish wrote:
> > > * Keep the current synthetic CPUID(0x4c780001) and CPUID(0x4c780002)
> > >   bitfield listings, with their hardware-backed scattered bits, as is.
> > >   Mark them as "v1" instead of setting them in stone.
> >
> > Except that they're already cast in stone:
> >
> > https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/tip/db/xml/leaf_4c780001.xml
> >
> > and that 02 one.
> >
> > I don't want any of that to be in any database - this is Linux-internal only
> > and needs to go from there and nothing should depend on it.
> >
> > So, instead of taking this and then converting stuff ontop, the proper thing
> > to do would be:
> >
> > - rip out the linux-specific leafs from the cpuid db
> > - keep both facilities in the kernel for querying and convert the hardware
> >   leafs to the new method but use the old method for querying the synthetic
> >   leafs. I'm sure we can multiplex between the two in cpu_feature_enabled()
> >
> > - then start converting the synthetic ones to hidden, Linux-specific ones
> >
> > Ok?
>
> 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?

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.)

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.)

That said, it would be good to get the initial set of commits
done so that db updates can start to flow in, to catch up...

--
C.

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

[Borislav Petkov]

On Tue, May 05, 2026 at 03:33:50PM +0200, Borislav Petkov wrote:
> On Mon, Apr 27, 2026 at 08:45:23PM +0200, Ahmed S. Darwish wrote:
> > * Keep the current synthetic CPUID(0x4c780001) and CPUID(0x4c780002)
> >   bitfield listings, with their hardware-backed scattered bits, as is.
> >   Mark them as "v1" instead of setting them in stone.
> 
> Except that they're already cast in stone:
> 
> https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/tip/db/xml/leaf_4c780001.xml
> 
> and that 02 one.
> 
> I don't want any of that to be in any database - this is Linux-internal only
> and needs to go from there and nothing should depend on it.
> 
> So, instead of taking this and then converting stuff ontop, the proper thing
> to do would be:
> 
> - rip out the linux-specific leafs from the cpuid db
> - keep both facilities in the kernel for querying and convert the hardware
>   leafs to the new method but use the old method for querying the synthetic
>   leafs. I'm sure we can multiplex between the two in cpu_feature_enabled()
> 
> - then start converting the synthetic ones to hidden, Linux-specific ones
> 
> Ok?

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?

-- 
Regards/Gruss,
    Boris.

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

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

[Borislav Petkov]

On Mon, Apr 27, 2026 at 08:45:23PM +0200, Ahmed S. Darwish wrote:
> * Keep the current synthetic CPUID(0x4c780001) and CPUID(0x4c780002)
>   bitfield listings, with their hardware-backed scattered bits, as is.
>   Mark them as "v1" instead of setting them in stone.

Except that they're already cast in stone:

https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/tip/db/xml/leaf_4c780001.xml

and that 02 one.

I don't want any of that to be in any database - this is Linux-internal only
and needs to go from there and nothing should depend on it.

So, instead of taking this and then converting stuff ontop, the proper thing
to do would be:

- rip out the linux-specific leafs from the cpuid db
- keep both facilities in the kernel for querying and convert the hardware
  leafs to the new method but use the old method for querying the synthetic
  leafs. I'm sure we can multiplex between the two in cpu_feature_enabled()

- then start converting the synthetic ones to hidden, Linux-specific ones

Ok?

-- 
Regards/Gruss,
    Boris.

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

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

[Ahmed S. Darwish]

On Tue, 21 Apr 2026, Maciej Wieczor-Retman wrote:
>
> I've now read through every patch and cross checked most things with the
> docs so I think everything plugs in where it should (aside from that
> transmeta.c thing that the kernel bot reported).
>

Thanks a lot!

>
> Only left comments on some code formatting stuff, typoes etc.
>

I'm in-progress rebasing the patch queue over -rc1 and have included all
your points.

Kind regards,
Ahmed

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

[Ahmed S. Darwish]

Hi Boris,

On Mon, 13 Apr 2026, Ahmed S. Darwish wrote:
>
> On Tue, 31 Mar 2026, Borislav Petkov wrote:
> >
> > 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.
> >
>
> I guess that's a very sensible plan.
>
> The X86_FEATURE integration and synthetic bits work is covered by the late
> part of the queue (patches #77 => #90), so I'll rework 'em to do the above.
>

So I prototyped this.

Removing the scattered hardware-backed feature bits from within synthetic
X86_FEATURE words (i.e. the ones listed in scattered.c) required changing
the mapping tables at patch (79/90), "x86/cpuid: Introduce a compile-time
X86_FEATURE word map", from:

    X86_FEATURE word => CPUID table word
to:

    X86_FEATURE bit => CPUID table bit

That prototype actually did that and included converting all the capability
code at common.c: apply_forced_caps(), identify_cpu(), store_cpu_caps(),
microcode_check(), etc.

That part actually worked fine.

But then there were a lot of places with deeply ingrained logic that deals
with X86_FEATURE in terms of words.  This includes KVM's reverse feature
maps, early 32-bit ASM code, the AWK and shell code generation build
scripts, early boot feature validation, feature naming tables, and others;
all relying on X86_FEATURE word access. [*]  At that point, this started
looking like as a new phase of the CPUID work.

So, my suggestion would be:

* Keep the current word-granular X86_FEATURE compile-time mappings.

* Keep the current synthetic CPUID(0x4c780001) and CPUID(0x4c780002)
  bitfield listings, with their hardware-backed scattered bits, as is.
  Mark them as "v1" instead of setting them in stone.

* Work on getting this large patch queue merged, and in the background I
  continue transitioning the remaining CPUID call sites to the CPUID API.

* Then, after all that is properly discussed and merged, I'll follow up
  with a separate series that converts the X86_FEATURE mappins from
  word-based to per-bit, together with the KVM, boot/asm, and build-time
  machinery that currently assumes X86_FEATURE word access.  At the end of
  that series, the hardware-backed bits within the Linux synthetic words
  can be removed; along with all the scattered.c code.

I understand that with the current design, querying a scattered X86_FEATURE
bit (say X86_FEATURE_APERFMPERF) might lead to a different result than
directly querying its backing CPUID leaf (CPUID(0x6).ECX[0]), but this is
already the state of the kernel as of today.  So IMHO better have all this
new CPUID code merged and widely tested in a kernel release first, then
work on that next.

[*] git grep -E '(NCAPINTS|NBUGINTS|REQUIRED_MASK|cpuid\.flags)' arch/x86/

Thanks a lot!
Ahmed

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

[Maciej Wieczor-Retman]

I've now read through every patch and cross checked most things with the docs so
I think everything plugs in where it should (aside from that transmeta.c thing
that the kernel bot reported). Only left comments on some code formatting stuff,
typoes etc.

-- 
Kind regards
Maciej Wieczór-Retman

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

[Ahmed S. Darwish]

Hi Maciej,

On Tue, 07 Apr 2026, Maciej Wieczor-Retman wrote:
>
> Hi, very cool rework! So far I didn't notice any problems while testing.
>

Thanks a lot for testing!

I will appreciate then adding a Tested-by tag on v7, where the interesting
bits will hopefully start to get merged.

>
> Buy anyway I wanted to ask if you thought about including the cpuid_deps[] or
> cpuid_dependent_features[] into the new cpuid API ecosystem?
>
> Or if not (since this patchset is quite long already :b ), then do you have any
> idea where best it could fit in? During discussion on [1] you mentioned the
> feature depenedency should be encoded in x86-cpuid-db. I assume you meant it
> would need to be first patched into there, then parsed by Kconfig?
>
> [1] https://lore.kernel.org/all/acruJf-pyld-fTh1@lx-t490/
>

Sorry, I'm just back from Easter vacations; that's why I didn't answer your
question in that other thread.

x86-cpuid-db will encode all the feature dependencies in its XML database.
Then it can generate all the necessary dependency structures, in a way that
is easy to parse for all kernel phases; including the kconfig build phase.

Then, what you want to do can be cleanly added on top.

P.S. I'm already removing <asm/cpufeatures.h> in the next iteration, along
with its ugly "/proc/cpuinfo names inside multi-line C comments" hack.

Kind regards,
Ahmed

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

[Ahmed S. Darwish]

Hi!

On Tue, 31 Mar 2026, Borislav Petkov wrote:
>
> 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.
>

I guess that's a very sensible plan.

The X86_FEATURE integration and synthetic bits work is covered by the late
part of the queue (patches #77 => #90), so I'll rework 'em to do the above.

Can I get some review feedback for the patches on top (patches #04 => #76)?
They shouldn't be affected by the requested X86_FEATURE changes.

Thanks,
Ahmed

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

[Maciej Wieczor-Retman]

Hi, very cool rework! So far I didn't notice any problems while testing.

Buy anyway I wanted to ask if you thought about including the cpuid_deps[] or
cpuid_dependent_features[] into the new cpuid API ecosystem?

Or if not (since this patchset is quite long already :b ), then do you have any
idea where best it could fit in? During discussion on [1] you mentioned the
feature depenedency should be encoded in x86-cpuid-db. I assume you meant it
would need to be first patched into there, then parsed by Kconfig?

[1] https://lore.kernel.org/all/acruJf-pyld-fTh1@lx-t490/

(resending the email as the in-reply-to got lost somehow and I wanted to correct
top posting)

-- 
Kind regards
Maciej Wieczór-Retman

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

[Borislav Petkov]

On Tue, Apr 07, 2026 at 08:55:07AM +0000, Maciej Wieczor-Retman wrote:
> Hi, very cool rework! So far I didn't notice any problems while testing.
> 
> Buy anyway I wanted to ask if you thought about including the cpuid_deps[] or
> cpuid_dependent_features[] into the new cpuid API ecosystem?
> 
> Or if not (since this patchset is quite long already :b ), then do you have
> any idea where best it could fit in? During discussion on [1] you mentioned the
> feature depenedency should be encoded in x86-cpuid-db. I assume you meant it
> would need to be first patched into there, then parsed by Kconfig?

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

-- 
Regards/Gruss,
    Boris.

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

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

[Maciej Wieczor-Retman]

Hi, very cool rework! So far I didn't notice any problems while testing.

Buy anyway I wanted to ask if you thought about including the cpuid_deps[] or
cpuid_dependent_features[] into the new cpuid API ecosystem?

Or if not (since this patchset is quite long already :b ), then do you have
any idea where best it could fit in? During discussion on [1] you mentioned the
feature depenedency should be encoded in x86-cpuid-db. I assume you meant it
would need to be first patched into there, then parsed by Kconfig?

Kind regards
Maciej Wieczór-Retman

[1] https://lore.kernel.org/all/acruJf-pyld-fTh1@lx-t490/

On 2026-03-27 at 03:15:14 +0100, Ahmed S. Darwish wrote:
>Hi,
>
>Introduce a centralized x86 CPUID model, tables, and API.
>
>Rationale for this work can be found at:
>
>    https://lore.kernel.org/lkml/874ixernra.ffs@tglx
>    https://gitlab.com/x86-cpuid.org/x86-cpuid-db
>
>By the end of this series, route all X86_FEATURE queries to the CPUID
>tables and fully remove x86_capability[].
>
>The introduced tables and APIs then become a "single source of truth" for
>all x86 feature state, both the hardware-backed and the Linux-synthetic.
>
>The series is divided as follows:
>
># Generic updates and fixes
>
>     1  ASoC: Intel: avs: Check maximum valid CPUID leaf
>     2  ASoC: Intel: avs: Include CPUID header at file scope
>     3  tools/x86/kcpuid: Update bitfields to x86-cpuid-db v3.0
>
># Header disentanglement (<asm/processor.h> <=> <asm/cpuid/api.h>)
>
>     4  treewide: Explicitly include the x86 CPUID headers
>     5  x86/cpu: <asm/processor.h>: Do not include the CPUID API header
>     6  x86/cpuid: Rename cpuid_leaf()/cpuid_subleaf() APIs
>     7  x86/cpuid: Introduce <asm/cpuid/leaf_types.h>
>
># CPUID Model (v6)
>
>     8  x86: Introduce a centralized CPUID data model
>     9  x86/cpuid: Introduce a centralized CPUID parser
>    10  x86/cpu: Rescan CPUID table after disabling PSN
>    11  x86/cpu: centaur/zhaoxin: Rescan CPUID(0xc0000001) after MSR writes
>    12  x86/cpu/transmeta: Rescan CPUID(0x1) after capability unhide
>    13  x86/cpu/intel: Rescan CPUID table after leaf unlock
>
># CPUID(0x0), CPUID(0x1), CPUID(0x80000000), CPUID(0x8000000[234])
>
>    14  x86/cpu: Use parsed CPUID(0x0)
>    15  x86/lib: Add CPUID(0x1) family and model calculation
>    16  x86/cpu: Use parsed CPUID(0x1)
>    17  x86/cpuid: Parse CPUID(0x80000000)
>    18  x86/cpu: Use parsed CPUID(0x80000000)
>    19  x86/cpuid: Parse CPUID(0x80000002) to CPUID(0x80000004)
>    20  x86/cpu: Use parsed CPUID(0x80000002) to CPUID(0x80000004)
>
># CPUID Model: x86 vendor discernment + debugfs support
>
>    21  x86/cpuid: Split parser tables and add vendor-qualified parsing
>    22  x86/cpuid: Introduce a parser debugfs interface
>
># CPUID(0x16), Transmeta CPUID(0x8086000[0123456]), Centaur CPUID(0xc000000[01])
>
>    23  x86/cpuid: Parse CPUID(0x16)
>    24  x86/tsc: Use parsed CPUID(0x16)
>    25  x86/cpuid: Parse Transmeta and Centaur extended ranges
>    26  x86/cpu: transmeta: Use parsed CPUID(0x80860000)->CPUID(0x80860006)
>    27  x86/cpu: transmeta: Refactor CPU information printing
>    28  x86/cpu: centaur: Use parsed CPUID(0xc0000001)
>    29  x86/cpu: zhaoxin: Use parsed CPUID(0xc0000001)
>
># Intel cache descriptors; CPUID(0x2)
>
>    30  x86/cpuid: Parse CPUID(0x2)
>    31  x86/cpuid: Warn once on invalid CPUID(0x2) iteration count
>    32  x86/cpuid: Introduce parsed CPUID(0x2) API
>    33  x86/cpu: Use parsed CPUID(0x2)
>    34  x86/cacheinfo: Use parsed CPUID(0x2)
>    35  x86/cpuid: Remove direct CPUID(0x2) query helpers
>
># Intel/AMD deterministic cache; CPUID(0x4), CPUID(0x8000001d)
>
>    36  x86/cpuid: Parse deterministic cache parameters CPUID leaves
>    37  x86/cacheinfo: Pass a 'struct cpuinfo_x86' refrence to CPUID(0x4) code
>    38  x86/cacheinfo: Use parsed CPUID(0x4)
>    39  x86/cacheinfo: Use parsed CPUID(0x8000001d)
>
># Cache/TLB/mm info; CPUID(0x8000000[568])
>
>    40  x86/cpuid: Parse CPUID(0x80000005), CPUID(0x80000006), CPUID(0x80000008)
>    41  x86/cacheinfo: Use auto-generated data types
>    42  x86/cacheinfo: Use parsed CPUID(0x80000005) and CPUID(0x80000006)
>    43  x86/cacheinfo: Use parsed CPUID(0x80000006)
>    44  x86/cpu: Use parsed CPUID(0x80000005) and CPUID(0x80000006)
>    45  x86/cpu/amd: Use parsed CPUID(0x80000005)
>    46  x86/cpu/amd: Refactor TLB detection code
>    47  x86/cpu/amd: Use parsed CPUID(CPUID(0x80000005) and CPUID(0x80000006)
>    48  x86/cpu/hygon: Use parsed CPUID(0x80000005) and CPUID(0x80000006)
>    49  x86/cpu/centaur: Use parsed CPUID(0x80000005)
>    50  x86/cpu: Use parsed CPUID(0x80000008)
>
># PerfMon; CPUID(0xa), CPUID(0x1c), CPUID(0x23), CPUID(0x80000022)
>
>    51  x86/cpuid: Parse CPUID(0xa) and CPUID(0x1c)
>    52  x86/cpu/intel: Use parsed CPUID(0xa)
>    53  x86/cpu/centaur: Use parsed CPUID(0xa)
>    54  x86/cpu/zhaoxin: Use parsed CPUID(0xa)
>    55  perf/x86/intel: Use parsed CPUID(0xa)
>    56  perf/x86/zhaoxin: Use parsed CPUID(0xa)
>    57  x86/xen: Use parsed CPUID(0xa)
>    58  KVM: x86: Use standard CPUID(0xa) types
>    59  KVM: x86/pmu: Use standard CPUID(0xa) types
>    60  perf/x86: Remove custom CPUID(0xa) types
>    61  perf/x86/lbr: Use parsed CPUID(0x1c)
>    62  perf/x86/lbr: Remove custom CPUID(0x1c) types
>    63  x86/cpuid: Parse CPUID(0x23)
>    64  perf/x86/intel: Use parsed per-CPU CPUID(0x23)
>    65  perf/x86/intel: Remove custom CPUID(0x23) types
>    66  x86/cpuid: Parse CPUID(0x80000022)
>    67  perf/x86/amd/lbr: Use parsed CPUID(0x80000022)
>    68  perf/x86/amd: Use parsed CPUID(0x80000022)
>    69  KVM: x86: Use standard CPUID(0x80000022) types
>    70  perf/x86: Remove custom CPUID(0x80000022) types
>
># Power management flags; CPUID(0x80000007).EBX
>
>    71  x86/cpuid: Parse CPUID(0x80000007)
>    72  x86/cpu: Use parsed CPUID(0x80000007)
>    73  x86/cpu: amd/hygon: Use parsed CPUID(0x80000007)
>    74  x86/cpu: cpuinfo: Use parsed CPUID(0x80000007)
>    75  KVM: x86: Use parsed CPUID(0x80000007)
>
># Model: X86_FEATURE routing to the CPUID tables
>
>    76  x86/microcode: Allocate cpuinfo_x86 snapshots on the heap
>    77  x86/cpuid: Parse leaves backing X86_FEATURE words
>    78  x86/cpuid: Parse Linux synthetic CPUID leaves
>    79  x86/cpuid: Introduce a compile-time X86_FEATURE word map
>    80  x86/cpuid: Introduce X86_FEATURE and CPUID word APIs
>    81  x86/percpu: Add offset argument to x86_this_cpu_test_bit()
>    82  x86/cpufeature: Factor out a __static_cpu_has() helper
>    83  x86/asm/32: Cache CPUID(0x1).EDX in cpuid_table
>    84  x86: Route all feature queries to the CPUID tables
>
># x86_capability[] removal
>
>    85  x86/cpu: Remove x86_capability[] and x86_power initialization
>    86  x86/cpu/transmeta: Remove x86_capability[] CPUID initialization
>    87  x86/cpu: centaur/zhaoxin: Remove x86_capability[] initialization
>    88  KVM: x86: Remove BUILD_BUG_ON() x86_capability[] check
>    89  x86/cpu: Remove x86_capability[] and x86_power
>
># Finally
>
>    90  MAINTAINERS: Extend x86 CPUID DATABASE file coverage
>
>Changelog v6
>============
>
>This iteration adds the following:
>
>(I.) X86_FEATURE integration
>----------------------------
>
>The X86_FEATURE words at <asm/cpufeatures.h> are of two kinds:
>
>(a.) Hardware-defined feature words, mirroring one CPUID output register
>(b.) Linux-defined x86 feature words
>
>For the hardware-backed words, the CPUID tables and x86_capability[] fully
>overlap.  Route those X86_FEATURE words to the CPUID tables instead.
>
>For the Linux-synthetic feature words, only x86_capability[] defines them
>as they have no hardware backing.  Unify their handling by defining them in
>x86-cpuid-db as a synthetic CPUID leaf:
>
><leaf id="0x4c780001">
>  <desc>Linux-defined synthetic feature flags</desc>
>  <text>
>    This is a Linux-defined synthetic CPUID leaf, where "Linux" is a
>    virtual vendor mirroring hardware vendors like AMD and Intel.  The leaf
>    ID prefix 0x4c78 is for Linux, in its shorthand ASCII form "Lx".
>
>    The bit listing mirrors what Linux defines in its synthetic X86_FEATURE
>    words.  The listed feature bits are expected to be stable, and
>    allocated new bits must be filled in that order: subleaf 0 (EAX->EDX),
>    subleaf 1 (EAX->EDX), and so on.
>  </text>
>  <vendors>
>    <vendor>Linux</vendor>
>  </vendors>
>  <subleaf id="0">
>    <eax>
>      <desc>X86_FEATURE word 3: Miscellaneous flags</desc>
>      <!-- .. bitfields .. -->
>    </eax>
>    <ebx>
>      <desc>X86_FEATURE word 7: Auxiliary flags</desc>
>      <!-- .. bitfields .. -->
>    </ebx>
>    <ecx>
>      <desc>X86_FEATURE word 8: Virtualization flags</desc>
>      <!-- .. bitfields .. -->
>    </ecx>
>    <!-- and so on -->
>  </subleaf>
></leaf>
>
>Cover all the synthetic feature and bug words by defining CPUID(0x4c780001)
>subleaf 0, CPUID(0x4c780001) subleaf 1, and CPUID(0x4c780002) for the CPU
>bugs words, X86_BUG.
>
>(II.) Preserve optimized X86_FEATURE query paths
>------------------------------------------------
>
>Feature querying is one of the hottest code paths in the x86 subsystem.
>This is evident from the bitops usage and the post-boot ALTERNATIVE_TERNARY
>opcode patching at <asm/cpufeature.h>.
>
>Preserve that fast path by implementing a pure compile-time mapping from an
>X86_FEATURE word to a CPUID table entry in <asm/cpuid/types.h>:
>
>#define CPUID_FEATURE_WORDS_MAP {						\
>    /*   X86_FEATURE word,	Leaf,		Subleaf,	Output reg */	\
>    __cpu_feature_word(0,	0x1,		0,		CPUID_EDX),	\
>    __cpu_feature_word(1,	0x80000001,	0,		CPUID_EDX),	\
>    __cpu_feature_word(2,	0x80860001,	0,		CPUID_EDX),	\
>    __cpu_feature_word(3,	0x4c780001,	0,		CPUID_EAX),	\
>    __cpu_feature_word(4,	0x1,		0,		CPUID_ECX),	\
>    __cpu_feature_word(5,	0xc0000001,	0,		CPUID_EDX),	\
>    __cpu_feature_word(6,	0x80000001,	0,		CPUID_ECX),	\
>    __cpu_feature_word(7,	0x4c780001,	0,		CPUID_EBX),	\
>    ...										\
>}
>
>Ensure that all mapped X86_FEATURE words remain "unsigned long" aligned so
>that bitops access continues to work.  Translate an X86_FEATURE query, at
>compile time, to a bitops-ready bitmap plus bit offset.
>
>The synthetic x86-cpuid-db CPUID leaves (0x4c78 range), remove any need to
>distinguish between synthetic and hardware-backed X86_FEATURE words.
>Across this whole series, treat both classes identically.
>
>(III.) Partial CPUID Table refresh APIs
>---------------------------------------
>
>The CPUID tables now host all the X86_FEATURE words, so /never/ repopulate
>those tables wholesale.  Doing so would corrupt the kernel maintained state
>of set and cleared feature bits, for both hardware-backed and synthetic
>words.  This is especially true since once all direct CPUID queries are
>forbidden from the kernel, the kernel will gain even more freedom to modify
>the hardware-backed feature bits at will.
>
>But... there are areas in the kernel where parts of the table need to be
>refreshed.  This can happen after MSR writes, where CPUID leaves can appear
>or disapper, or individual feature bits within them can get set or cleared.
>
>To handle that, introduce the partial CPUID table refresh APIs:
>
>    void cpuid_refresh_leaf(struct cpuinfo_x86 *c, u32 leaf);
>    void cpuid_refresh_range(struct cpuinfo_x86 *c, u32 start, u32 end);
>
>The CPUID tables are not a normal array, but a compile-time collection of
>different types.  Nonetheless, a reliable implementation was found to
>bridge the compile-time layout and the run-time partial refresh logic.
>
>(IV.) Convert more CPUID leaves
>-------------------------------
>
>Convert many more call sites to the new CPUID APIs, in the ongoing quest to
>forbid the CPUID instruction in all kernel code outside the CPUID parser.
>
>Parse the CPUID leaves required for hardware-backed X86_FEATURE words:
>
>    CPUID(0x6)
>    CPUID(0x7).0
>    CPUID(0x7).1
>    CPUID(0xd).1
>    CPUID(0x80000001)
>    CPUID(0x80000007)
>    CPUID(0x80000008)
>    CPUID(0x8000000a)
>    CPUID(0x8000001f)
>    CPUID(0x80000021)
>
>Parse all Transmeta and Centaur/Zhaoxin leaves, and convert their call
>sites:
>
>    CPUID(0x80860000)
>    CPUID(0x80860001)
>    CPUID(0x80860002)
>    CPUID(0x80860003)
>    CPUID(0x80860004)
>    CPUID(0x80860005)
>    CPUID(0x80860006)
>    CPUID(0xc0000000)
>    CPUID(0xc0000001)
>
>Parse and convert the call sites for the performance monitoring
>(PerfMon) leaves:
>
>    CPUID(0xa)
>    CPUID(0x1c)
>    CPUID(0x23)
>    CPUID(0x80000022)
>
>Remove the custom CPUID output types from perf's <asm/perf_event.h> and
>use the auto generated x86-cpuid-db output types instead.
>
>Complete all call-site conversions for:
>
>    CPUID(0x80000005)
>    CPUID(0x80000006)
>    CPUID(0x80000008)
>
>Previous iterations converted only the cacheinfo.c logic. This iteration
>also converts cpu/common.c, cpu/centaur.c, and cpu/zhaoxin.c.
>
>(V.) Handle Boris' review remarks
>---------------------------------
>
>Get rid of the "static vs. dynamic" CPUID leaf distinction, since that
>terminology does not exist in the hardware manuals. What was previously
>called a dynamic leaf is now described simply as a leaf with a subleaf
>range.  Adjust the CPUID API function names and update all their
>kernel-doc.
>
>Reduce commit log verbosity where appropriate.  In general, keep detailed
>kernel-doc only for the exported call-site APIs.
>
>Shorten function names for the CPUID parser call-site APIs; e.g.
>cpuid_parse_cpu(), cpuid_refresh_leaf(), etc.
>
>(VI.) State of affairs
>----------------------
>
>Besides the X86_FEATURE query routing, 36 CPUID leaves are now converted
>to the CPUID API.  Namely:
>
>    CPUID(0x0)
>    CPUID(0x1)
>    CPUID(0x2)
>    CPUID(0x4)
>    CPUID(0x6)
>    CPUID(0x7)
>    CPUID(0x7).1
>    CPUID(0xa)
>    CPUID(0xd).1
>    CPUID(0x16)
>    CPUID(0x1c)
>    CPUID(0x23)
>    CPUID(0x23).1
>    CPUID(0x23).2
>    CPUID(0x80000000)
>    CPUID(0x80000001)
>    CPUID(0x80000002)
>    CPUID(0x80000003)
>    CPUID(0x80000004)
>    CPUID(0x80000005)
>    CPUID(0x80000006)
>    CPUID(0x80000007)
>    CPUID(0x80000008)
>    CPUID(0x8000000a)
>    CPUID(0x8000001d)
>    CPUID(0x8000001f)
>    CPUID(0x80000021)
>    CPUID(0x80000022)
>    CPUID(0x80860000)
>    CPUID(0x80860001)
>    CPUID(0x80860002)
>    CPUID(0x80860003)
>    CPUID(0x80860004)
>    CPUID(0x80860005)
>    CPUID(0x80860006)
>    CPUID(0xc0000000)
>    CPUID(0xc0000001)
>
>(VII.) Previous iterations
>--------------------------
>
>Previous iterations of this work document the evolution of the call site
>CPUID APIs.  Please see:
>
>    (v5) https://lore.kernel.org/lkml/20250905121515.192792-1-darwi@linutronix.de
>
>The cover letter there details the v1-v5 progression in full.
>
>Thank you!
>Ahmed
>
>8<-----
>
>base-commit: c369299895a591d96745d6492d4888259b004a9e
>-- 
>2.53.0

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

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

[Ahmed S. Darwish]

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

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

[Borislav Petkov]

On Fri, Mar 27, 2026 at 03:15:14AM +0100, Ahmed S. Darwish wrote:
> For the Linux-synthetic feature words, only x86_capability[] defines them
> as they have no hardware backing.  Unify their handling by defining them in
> x86-cpuid-db as a synthetic CPUID leaf:
> 
> <leaf id="0x4c780001">
>   <desc>Linux-defined synthetic feature flags</desc>

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.

Thx.

-- 
Regards/Gruss,
    Boris.

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

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

[Ahmed S. Darwish]

Hi,

Introduce a centralized x86 CPUID model, tables, and API.

Rationale for this work can be found at:

    https://lore.kernel.org/lkml/874ixernra.ffs@tglx
    https://gitlab.com/x86-cpuid.org/x86-cpuid-db

By the end of this series, route all X86_FEATURE queries to the CPUID
tables and fully remove x86_capability[].

The introduced tables and APIs then become a "single source of truth" for
all x86 feature state, both the hardware-backed and the Linux-synthetic.

The series is divided as follows:

# Generic updates and fixes

     1  ASoC: Intel: avs: Check maximum valid CPUID leaf
     2  ASoC: Intel: avs: Include CPUID header at file scope
     3  tools/x86/kcpuid: Update bitfields to x86-cpuid-db v3.0

# Header disentanglement (<asm/processor.h> <=> <asm/cpuid/api.h>)

     4  treewide: Explicitly include the x86 CPUID headers
     5  x86/cpu: <asm/processor.h>: Do not include the CPUID API header
     6  x86/cpuid: Rename cpuid_leaf()/cpuid_subleaf() APIs
     7  x86/cpuid: Introduce <asm/cpuid/leaf_types.h>

# CPUID Model (v6)

     8  x86: Introduce a centralized CPUID data model
     9  x86/cpuid: Introduce a centralized CPUID parser
    10  x86/cpu: Rescan CPUID table after disabling PSN
    11  x86/cpu: centaur/zhaoxin: Rescan CPUID(0xc0000001) after MSR writes
    12  x86/cpu/transmeta: Rescan CPUID(0x1) after capability unhide
    13  x86/cpu/intel: Rescan CPUID table after leaf unlock

# CPUID(0x0), CPUID(0x1), CPUID(0x80000000), CPUID(0x8000000[234])

    14  x86/cpu: Use parsed CPUID(0x0)
    15  x86/lib: Add CPUID(0x1) family and model calculation
    16  x86/cpu: Use parsed CPUID(0x1)
    17  x86/cpuid: Parse CPUID(0x80000000)
    18  x86/cpu: Use parsed CPUID(0x80000000)
    19  x86/cpuid: Parse CPUID(0x80000002) to CPUID(0x80000004)
    20  x86/cpu: Use parsed CPUID(0x80000002) to CPUID(0x80000004)

# CPUID Model: x86 vendor discernment + debugfs support

    21  x86/cpuid: Split parser tables and add vendor-qualified parsing
    22  x86/cpuid: Introduce a parser debugfs interface

# CPUID(0x16), Transmeta CPUID(0x8086000[0123456]), Centaur CPUID(0xc000000[01])

    23  x86/cpuid: Parse CPUID(0x16)
    24  x86/tsc: Use parsed CPUID(0x16)
    25  x86/cpuid: Parse Transmeta and Centaur extended ranges
    26  x86/cpu: transmeta: Use parsed CPUID(0x80860000)->CPUID(0x80860006)
    27  x86/cpu: transmeta: Refactor CPU information printing
    28  x86/cpu: centaur: Use parsed CPUID(0xc0000001)
    29  x86/cpu: zhaoxin: Use parsed CPUID(0xc0000001)

# Intel cache descriptors; CPUID(0x2)

    30  x86/cpuid: Parse CPUID(0x2)
    31  x86/cpuid: Warn once on invalid CPUID(0x2) iteration count
    32  x86/cpuid: Introduce parsed CPUID(0x2) API
    33  x86/cpu: Use parsed CPUID(0x2)
    34  x86/cacheinfo: Use parsed CPUID(0x2)
    35  x86/cpuid: Remove direct CPUID(0x2) query helpers

# Intel/AMD deterministic cache; CPUID(0x4), CPUID(0x8000001d)

    36  x86/cpuid: Parse deterministic cache parameters CPUID leaves
    37  x86/cacheinfo: Pass a 'struct cpuinfo_x86' refrence to CPUID(0x4) code
    38  x86/cacheinfo: Use parsed CPUID(0x4)
    39  x86/cacheinfo: Use parsed CPUID(0x8000001d)

# Cache/TLB/mm info; CPUID(0x8000000[568])

    40  x86/cpuid: Parse CPUID(0x80000005), CPUID(0x80000006), CPUID(0x80000008)
    41  x86/cacheinfo: Use auto-generated data types
    42  x86/cacheinfo: Use parsed CPUID(0x80000005) and CPUID(0x80000006)
    43  x86/cacheinfo: Use parsed CPUID(0x80000006)
    44  x86/cpu: Use parsed CPUID(0x80000005) and CPUID(0x80000006)
    45  x86/cpu/amd: Use parsed CPUID(0x80000005)
    46  x86/cpu/amd: Refactor TLB detection code
    47  x86/cpu/amd: Use parsed CPUID(CPUID(0x80000005) and CPUID(0x80000006)
    48  x86/cpu/hygon: Use parsed CPUID(0x80000005) and CPUID(0x80000006)
    49  x86/cpu/centaur: Use parsed CPUID(0x80000005)
    50  x86/cpu: Use parsed CPUID(0x80000008)

# PerfMon; CPUID(0xa), CPUID(0x1c), CPUID(0x23), CPUID(0x80000022)

    51  x86/cpuid: Parse CPUID(0xa) and CPUID(0x1c)
    52  x86/cpu/intel: Use parsed CPUID(0xa)
    53  x86/cpu/centaur: Use parsed CPUID(0xa)
    54  x86/cpu/zhaoxin: Use parsed CPUID(0xa)
    55  perf/x86/intel: Use parsed CPUID(0xa)
    56  perf/x86/zhaoxin: Use parsed CPUID(0xa)
    57  x86/xen: Use parsed CPUID(0xa)
    58  KVM: x86: Use standard CPUID(0xa) types
    59  KVM: x86/pmu: Use standard CPUID(0xa) types
    60  perf/x86: Remove custom CPUID(0xa) types
    61  perf/x86/lbr: Use parsed CPUID(0x1c)
    62  perf/x86/lbr: Remove custom CPUID(0x1c) types
    63  x86/cpuid: Parse CPUID(0x23)
    64  perf/x86/intel: Use parsed per-CPU CPUID(0x23)
    65  perf/x86/intel: Remove custom CPUID(0x23) types
    66  x86/cpuid: Parse CPUID(0x80000022)
    67  perf/x86/amd/lbr: Use parsed CPUID(0x80000022)
    68  perf/x86/amd: Use parsed CPUID(0x80000022)
    69  KVM: x86: Use standard CPUID(0x80000022) types
    70  perf/x86: Remove custom CPUID(0x80000022) types

# Power management flags; CPUID(0x80000007).EBX

    71  x86/cpuid: Parse CPUID(0x80000007)
    72  x86/cpu: Use parsed CPUID(0x80000007)
    73  x86/cpu: amd/hygon: Use parsed CPUID(0x80000007)
    74  x86/cpu: cpuinfo: Use parsed CPUID(0x80000007)
    75  KVM: x86: Use parsed CPUID(0x80000007)

# Model: X86_FEATURE routing to the CPUID tables

    76  x86/microcode: Allocate cpuinfo_x86 snapshots on the heap
    77  x86/cpuid: Parse leaves backing X86_FEATURE words
    78  x86/cpuid: Parse Linux synthetic CPUID leaves
    79  x86/cpuid: Introduce a compile-time X86_FEATURE word map
    80  x86/cpuid: Introduce X86_FEATURE and CPUID word APIs
    81  x86/percpu: Add offset argument to x86_this_cpu_test_bit()
    82  x86/cpufeature: Factor out a __static_cpu_has() helper
    83  x86/asm/32: Cache CPUID(0x1).EDX in cpuid_table
    84  x86: Route all feature queries to the CPUID tables

# x86_capability[] removal

    85  x86/cpu: Remove x86_capability[] and x86_power initialization
    86  x86/cpu/transmeta: Remove x86_capability[] CPUID initialization
    87  x86/cpu: centaur/zhaoxin: Remove x86_capability[] initialization
    88  KVM: x86: Remove BUILD_BUG_ON() x86_capability[] check
    89  x86/cpu: Remove x86_capability[] and x86_power

# Finally

    90  MAINTAINERS: Extend x86 CPUID DATABASE file coverage

Changelog v6
============

This iteration adds the following:

(I.) X86_FEATURE integration
----------------------------

The X86_FEATURE words at <asm/cpufeatures.h> are of two kinds:

(a.) Hardware-defined feature words, mirroring one CPUID output register
(b.) Linux-defined x86 feature words

For the hardware-backed words, the CPUID tables and x86_capability[] fully
overlap.  Route those X86_FEATURE words to the CPUID tables instead.

For the Linux-synthetic feature words, only x86_capability[] defines them
as they have no hardware backing.  Unify their handling by defining them in
x86-cpuid-db as a synthetic CPUID leaf:

<leaf id="0x4c780001">
  <desc>Linux-defined synthetic feature flags</desc>
  <text>
    This is a Linux-defined synthetic CPUID leaf, where "Linux" is a
    virtual vendor mirroring hardware vendors like AMD and Intel.  The leaf
    ID prefix 0x4c78 is for Linux, in its shorthand ASCII form "Lx".

    The bit listing mirrors what Linux defines in its synthetic X86_FEATURE
    words.  The listed feature bits are expected to be stable, and
    allocated new bits must be filled in that order: subleaf 0 (EAX->EDX),
    subleaf 1 (EAX->EDX), and so on.
  </text>
  <vendors>
    <vendor>Linux</vendor>
  </vendors>
  <subleaf id="0">
    <eax>
      <desc>X86_FEATURE word 3: Miscellaneous flags</desc>
      <!-- .. bitfields .. -->
    </eax>
    <ebx>
      <desc>X86_FEATURE word 7: Auxiliary flags</desc>
      <!-- .. bitfields .. -->
    </ebx>
    <ecx>
      <desc>X86_FEATURE word 8: Virtualization flags</desc>
      <!-- .. bitfields .. -->
    </ecx>
    <!-- and so on -->
  </subleaf>
</leaf>

Cover all the synthetic feature and bug words by defining CPUID(0x4c780001)
subleaf 0, CPUID(0x4c780001) subleaf 1, and CPUID(0x4c780002) for the CPU
bugs words, X86_BUG.

(II.) Preserve optimized X86_FEATURE query paths
------------------------------------------------

Feature querying is one of the hottest code paths in the x86 subsystem.
This is evident from the bitops usage and the post-boot ALTERNATIVE_TERNARY
opcode patching at <asm/cpufeature.h>.

Preserve that fast path by implementing a pure compile-time mapping from an
X86_FEATURE word to a CPUID table entry in <asm/cpuid/types.h>:

#define CPUID_FEATURE_WORDS_MAP {						\
    /*   X86_FEATURE word,	Leaf,		Subleaf,	Output reg */	\
    __cpu_feature_word(0,	0x1,		0,		CPUID_EDX),	\
    __cpu_feature_word(1,	0x80000001,	0,		CPUID_EDX),	\
    __cpu_feature_word(2,	0x80860001,	0,		CPUID_EDX),	\
    __cpu_feature_word(3,	0x4c780001,	0,		CPUID_EAX),	\
    __cpu_feature_word(4,	0x1,		0,		CPUID_ECX),	\
    __cpu_feature_word(5,	0xc0000001,	0,		CPUID_EDX),	\
    __cpu_feature_word(6,	0x80000001,	0,		CPUID_ECX),	\
    __cpu_feature_word(7,	0x4c780001,	0,		CPUID_EBX),	\
    ...										\
}

Ensure that all mapped X86_FEATURE words remain "unsigned long" aligned so
that bitops access continues to work.  Translate an X86_FEATURE query, at
compile time, to a bitops-ready bitmap plus bit offset.

The synthetic x86-cpuid-db CPUID leaves (0x4c78 range), remove any need to
distinguish between synthetic and hardware-backed X86_FEATURE words.
Across this whole series, treat both classes identically.

(III.) Partial CPUID Table refresh APIs
---------------------------------------

The CPUID tables now host all the X86_FEATURE words, so /never/ repopulate
those tables wholesale.  Doing so would corrupt the kernel maintained state
of set and cleared feature bits, for both hardware-backed and synthetic
words.  This is especially true since once all direct CPUID queries are
forbidden from the kernel, the kernel will gain even more freedom to modify
the hardware-backed feature bits at will.

But... there are areas in the kernel where parts of the table need to be
refreshed.  This can happen after MSR writes, where CPUID leaves can appear
or disapper, or individual feature bits within them can get set or cleared.

To handle that, introduce the partial CPUID table refresh APIs:

    void cpuid_refresh_leaf(struct cpuinfo_x86 *c, u32 leaf);
    void cpuid_refresh_range(struct cpuinfo_x86 *c, u32 start, u32 end);

The CPUID tables are not a normal array, but a compile-time collection of
different types.  Nonetheless, a reliable implementation was found to
bridge the compile-time layout and the run-time partial refresh logic.

(IV.) Convert more CPUID leaves
-------------------------------

Convert many more call sites to the new CPUID APIs, in the ongoing quest to
forbid the CPUID instruction in all kernel code outside the CPUID parser.

Parse the CPUID leaves required for hardware-backed X86_FEATURE words:

    CPUID(0x6)
    CPUID(0x7).0
    CPUID(0x7).1
    CPUID(0xd).1
    CPUID(0x80000001)
    CPUID(0x80000007)
    CPUID(0x80000008)
    CPUID(0x8000000a)
    CPUID(0x8000001f)
    CPUID(0x80000021)

Parse all Transmeta and Centaur/Zhaoxin leaves, and convert their call
sites:

    CPUID(0x80860000)
    CPUID(0x80860001)
    CPUID(0x80860002)
    CPUID(0x80860003)
    CPUID(0x80860004)
    CPUID(0x80860005)
    CPUID(0x80860006)
    CPUID(0xc0000000)
    CPUID(0xc0000001)

Parse and convert the call sites for the performance monitoring
(PerfMon) leaves:

    CPUID(0xa)
    CPUID(0x1c)
    CPUID(0x23)
    CPUID(0x80000022)

Remove the custom CPUID output types from perf's <asm/perf_event.h> and
use the auto generated x86-cpuid-db output types instead.

Complete all call-site conversions for:

    CPUID(0x80000005)
    CPUID(0x80000006)
    CPUID(0x80000008)

Previous iterations converted only the cacheinfo.c logic. This iteration
also converts cpu/common.c, cpu/centaur.c, and cpu/zhaoxin.c.

(V.) Handle Boris' review remarks
---------------------------------

Get rid of the "static vs. dynamic" CPUID leaf distinction, since that
terminology does not exist in the hardware manuals. What was previously
called a dynamic leaf is now described simply as a leaf with a subleaf
range.  Adjust the CPUID API function names and update all their
kernel-doc.

Reduce commit log verbosity where appropriate.  In general, keep detailed
kernel-doc only for the exported call-site APIs.

Shorten function names for the CPUID parser call-site APIs; e.g.
cpuid_parse_cpu(), cpuid_refresh_leaf(), etc.

(VI.) State of affairs
----------------------

Besides the X86_FEATURE query routing, 36 CPUID leaves are now converted
to the CPUID API.  Namely:

    CPUID(0x0)
    CPUID(0x1)
    CPUID(0x2)
    CPUID(0x4)
    CPUID(0x6)
    CPUID(0x7)
    CPUID(0x7).1
    CPUID(0xa)
    CPUID(0xd).1
    CPUID(0x16)
    CPUID(0x1c)
    CPUID(0x23)
    CPUID(0x23).1
    CPUID(0x23).2
    CPUID(0x80000000)
    CPUID(0x80000001)
    CPUID(0x80000002)
    CPUID(0x80000003)
    CPUID(0x80000004)
    CPUID(0x80000005)
    CPUID(0x80000006)
    CPUID(0x80000007)
    CPUID(0x80000008)
    CPUID(0x8000000a)
    CPUID(0x8000001d)
    CPUID(0x8000001f)
    CPUID(0x80000021)
    CPUID(0x80000022)
    CPUID(0x80860000)
    CPUID(0x80860001)
    CPUID(0x80860002)
    CPUID(0x80860003)
    CPUID(0x80860004)
    CPUID(0x80860005)
    CPUID(0x80860006)
    CPUID(0xc0000000)
    CPUID(0xc0000001)

(VII.) Previous iterations
--------------------------

Previous iterations of this work document the evolution of the call site
CPUID APIs.  Please see:

    (v5) https://lore.kernel.org/lkml/20250905121515.192792-1-darwi@linutronix.de

The cover letter there details the v1-v5 progression in full.

Thank you!
Ahmed

8<-----

base-commit: c369299895a591d96745d6492d4888259b004a9e
-- 
2.53.0