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

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

[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

[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 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

[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 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

[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

[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

[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

[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

[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

[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

[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 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Borislav Petkov]

On Fri, Mar 27, 2026 at 03:15:24AM +0100, Ahmed S. Darwish wrote:
> On Pentium-III and Transmeta CPUs, disabling the CPUID(0x3) Processor
> Serial Number (PSN) can affect the maximum valid CPUID standard leaf.
> 
> Rescan the CPU's CPUID table in that case not to have stale cached data.
> Rescan only the changed CPUID leaves, not to override any of the kernel's
> previously force-set or unset cached CPUID bits.
> 
> Rename squash_the_stupid_serial_number() to disable_cpu_serial_number() and
> explain the rationale behind disabling the CPU's PSN.

Except that those changes do not belong in this set. So I zapped them, see
below.

Also, why are you doing this min_t thing?

+       rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
+       cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);
+       c->cpuid_level = l0->max_std_leaf;

Wny not simply:

        /* Disabling CPUID(0x3) can change the maximum base CPUID level. */
        cpuid_refresh_leaf(c, 0x0);
        l0 = cpuid_leaf(c, 0x0);
        if (!l0)
                return;
 
        /* Rescan from the new maximum base CPUID level. */
        cpuid_refresh_range(c, l0->max_std_leaf + 1, CPUID_BASE_END);
        c->cpuid_level = l0->max_std_leaf;


commit 6ee288c96f9b701f71140e86d20cd16df778afba
Author: Ahmed S. Darwish <darwi@linutronix.de>
Date:   Fri Mar 27 03:15:24 2026 +0100

    x86/cpu: Rescan CPUID table after disabling PSN
    
    On Pentium-III and Transmeta CPUs, disabling the CPUID(0x3) Processor
    Serial Number (PSN) can affect the maximum valid CPUID standard leaf.
    
    Rescan the CPUID table in that case in order not to have stale cached data.
    Rescan only the changed CPUID leaves, not to override any of the kernel's
    previously force-set or unset cached CPUID bits.
    
      [ bp: Zap unrelated changes. ]
    
    Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/all/20260327021645.555257-1-darwi@linutronix.de

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a3df21d26460..01b64d04eb3b 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -339,13 +339,14 @@ bool cpuid_feature(void)
 
 static void squash_the_stupid_serial_number(struct cpuinfo_x86 *c)
 {
+	const struct leaf_0x0_0 *l0;
+	unsigned int rescan_from;
 	unsigned long lo, hi;
 
 	if (!cpu_has(c, X86_FEATURE_PN) || !disable_x86_serial_nr)
 		return;
 
 	/* Disable processor serial number: */
-
 	rdmsr(MSR_IA32_BBL_CR_CTL, lo, hi);
 	lo |= 0x200000;
 	wrmsr(MSR_IA32_BBL_CR_CTL, lo, hi);
@@ -353,8 +354,15 @@ static void squash_the_stupid_serial_number(struct cpuinfo_x86 *c)
 	pr_notice("CPU serial number disabled.\n");
 	clear_cpu_cap(c, X86_FEATURE_PN);
 
-	/* Disabling the serial number may affect the cpuid level */
-	c->cpuid_level = cpuid_eax(0);
+	/* Disabling CPUID(0x3) can change the maximum standard CPUID level. */
+	cpuid_refresh_leaf(c, 0x0);
+	l0 = cpuid_leaf(c, 0x0);
+	if (!l0)
+		return;
+
+	rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
+	cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);
+	c->cpuid_level = l0->max_std_leaf;
 }
 
 static int __init x86_serial_nr_setup(char *s)

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Ahmed S. Darwish]

Hi Boris,

On Mon, 11 May 2026, Borislav Petkov wrote:
>
> Except that those changes do not belong in this set. So I zapped them, see
> below.
>

Yeah, fair enough.

> Also, why are you doing this min_t thing?
>
> +       rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
> +       cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);
> +       c->cpuid_level = l0->max_std_leaf;
>

The min_t() logic is meant to handle both max-CPUID-level increases and
decreases after the MSR write.

Assuming a machine with PSN and CPUID(0x3) as the max standard level:

	c->cpuid_level == 3

	-> MSR write, disable PSN
	-> hardware: Max CPUID level becomes 2

	Refresh CPUID(0x0)
	l0->max_std_leaf == 2
	cpuid_refresh_range(c, min(2, 3) + 1, CPUID_BASE_END)

Then, the CPUID parser will avoid touching CPUID(0x1) and CPUID(0x2) and
zero the table from CPUID(0x3) upwards.

Similarly, at patch (13/90), "x86/cpu/intel: Rescan CPUID table after leaf
unlock":

	c->cpuid_level == 2

	-> MSR write, disable BIOS limiting all leafs > CPUID(0x2)
	-> hardware: Max CPUID level becomes 8

	Refresh CPUID(0x0)
	l0->max_std_leaf == 8
	cpuid_refresh_range(c, min(2, 8) + 1, CPUID_BASE_END)

Then the CPUID parser will zero and refresh all leaves from CPUID(0x3)
upwards.

So the min_t()'s intent is just to be defensive against hardware surprises.

If you think this is superfulous, then ACK, removing it will not harm.

Thanks!
Ahmed

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Borislav Petkov]

On Tue, May 12, 2026 at 09:12:25AM +0200, Ahmed S. Darwish wrote:
> So the min_t()'s intent is just to be defensive against hardware surprises.

But when you read l0->max_std_leaf, you always get the current, highest base
level. So there's nothing to protect against.

Or am I missing something?

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Borislav Petkov]

On Tue, May 12, 2026 at 04:34:12PM +0200, Borislav Petkov wrote:
> On Tue, May 12, 2026 at 09:12:25AM +0200, Ahmed S. Darwish wrote:
> > So the min_t()'s intent is just to be defensive against hardware surprises.
> 
> But when you read l0->max_std_leaf, you always get the current, highest base
> level. So there's nothing to protect against.
> 
> Or am I missing something?

Yeah, I am... might skip some leafs depending on how the max leaf changes.

So, just to be on the safe side, let's simply rescan the whole range again.

Diff ontop.

---
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 01b64d04eb3b..c51cdcad7875 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -340,7 +340,6 @@ bool cpuid_feature(void)
 static void squash_the_stupid_serial_number(struct cpuinfo_x86 *c)
 {
 	const struct leaf_0x0_0 *l0;
-	unsigned int rescan_from;
 	unsigned long lo, hi;
 
 	if (!cpu_has(c, X86_FEATURE_PN) || !disable_x86_serial_nr)
@@ -354,15 +353,16 @@ static void squash_the_stupid_serial_number(struct cpuinfo_x86 *c)
 	pr_notice("CPU serial number disabled.\n");
 	clear_cpu_cap(c, X86_FEATURE_PN);
 
-	/* Disabling CPUID(0x3) can change the maximum standard CPUID level. */
+	/* Disabling CPUID(0x3) can change the maximum base CPUID level. */
 	cpuid_refresh_leaf(c, 0x0);
 	l0 = cpuid_leaf(c, 0x0);
 	if (!l0)
 		return;
 
-	rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
-	cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);
 	c->cpuid_level = l0->max_std_leaf;
+
+	/* Rescan from the whole range. */
+	cpuid_refresh_range(c, 0, CPUID_BASE_END);
 }
 
 static int __init x86_serial_nr_setup(char *s)

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Ahmed S. Darwish]

On Wed, 13 May 2026, Borislav Petkov wrote:
>
> index 01b64d04eb3b..c51cdcad7875 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
...
>  	clear_cpu_cap(c, X86_FEATURE_PN);
...
>
> -	rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
> -	cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);
>  	c->cpuid_level = l0->max_std_leaf;
> +
> +	/* Rescan from the whole range. */
> +	cpuid_refresh_range(c, 0, CPUID_BASE_END);
>  }
>

That will break the clear_cpu_cap() just some few lines above it.  That is,
it will reset all feature flags force set or unset by the kernel.

I'm sending another patch queue iteration shortly that have a new API
function abstracting this min_t() logic in its own parser function, along
with better documentation:

    https://lkml.kernel.org/agSfWTxs9pRPHJxl@lx-t490/

The few CPUID patches now merged at tip:x86/cpu will also be in that patch
queue so that everything applies cleanly over -rc3.

Sounds good?

Thanks!
Ahmed

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Borislav Petkov]

On Wed, May 13, 2026 at 06:06:37PM +0200, Ahmed S. Darwish wrote:
> That will break the clear_cpu_cap() just some few lines above it.  That is,
> it will reset all feature flags force set or unset by the kernel.

We do
	apply_forced_caps(c);

later in identify_cpu().

I think you mean whatever has done clear_cpu_cap() which doesn't use the
cpu_caps_cleared/set arrays.

> I'm sending another patch queue iteration shortly that have a new API
> function abstracting this min_t() logic in its own parser function, along
> with better documentation:
> 
>     https://lkml.kernel.org/agSfWTxs9pRPHJxl@lx-t490/

And I don't want to pay attention to which ranges I've parsed and which
I haven't. That's too fragile. I want to simply rescan the whole thing and be
up-to-date.

Also, what guarantees that this thing:

	rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
	cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);

doesn't overwrite some unrelated ranges?

Also, in your example:


* First case:

           leaf 0x0
	   leaf 0x1
	   leaf 0x2     <- Old max CPUID
	   leaf 0x3
	   leaf 0x4
	   leaf 0x5
	   leaf 0x6
	   leaf 0x7
	   leaf 0x9     <- *New* max CPUID

when you rescan and overwrite [2-9], what guarantees that you don't overwrite
an already set or cleared bit in those new leafs, say in leaf 5?

Neither set_cpu_cap() nor clear_cpu_cap() pay attention to the max base leaf
value?

IOW, I *think* we want to be on the safe side and reread *only* the leaf we
disabled.

I guess we need to know which leaf changes when a MSR bit is toggled and
rescan only that leaf alone.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Borislav Petkov]

On Wed, May 13, 2026 at 06:51:28PM +0200, Borislav Petkov wrote:
> I guess we need to know which leaf changes when a MSR bit is toggled and
> rescan only that leaf alone.

And looking at the current code there:

        /* Disabling the serial number may affect the cpuid level */
        c->cpuid_level = cpuid_eax(0);

So why do you need to rescan leafs at all?

We don't have to do them now...

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[H. Peter Anvin]

On May 13, 2026 10:09:32 AM PDT, Borislav Petkov <bp@alien8.de> wrote:
>On Wed, May 13, 2026 at 06:51:28PM +0200, Borislav Petkov wrote:
>> I guess we need to know which leaf changes when a MSR bit is toggled and
>> rescan only that leaf alone.
>
>And looking at the current code there:
>
>        /* Disabling the serial number may affect the cpuid level */
>        c->cpuid_level = cpuid_eax(0);
>
>So why do you need to rescan leafs at all?
>
>We don't have to do them now...
>

Not to mention that the only change this *specific* leaf could cause is a change from 2 to 1. The only reason it matters at all is that the number of leaves is reported in /proc/cpuinfo for purely historical reasons (it is completely useless information since parsing CPUID these days requires a lot more than that piece of information.)

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Ahmed S. Darwish]

On Wed, 13 May 2026, Borislav Petkov wrote:
>
> I think you mean whatever has done clear_cpu_cap() which doesn't use the
> cpu_caps_cleared/set arrays.
>

Exactly.

There are almost a 100 call sites which directly do a set_cpu_cap():

    git grep 'set_cpu_cap(c, X86' arch/x86/

And none of those goes through the cpu_caps_set[] array, and thus into the
apply_forced_caps() thing.  The bit is just directly set through bitops.

So, resetting the CPUID table whole sale will drastically alter the x86
subystem behavior here.

> > I'm sending another patch queue iteration shortly that have a new API
> > function abstracting this min_t() logic in its own parser function, along
> > with better documentation:
> >
> >     https://lkml.kernel.org/agSfWTxs9pRPHJxl@lx-t490/
>
> And I don't want to pay attention to which ranges I've parsed and which I
> haven't. That's too fragile. I want to simply rescan the whole thing and
> be up-to-date.

Yes, but AFAIK this changes kernel behavior to (what is at least to me) a
now-unknown behavior.

>
> Also, what guarantees that this thing:
>
> 	rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
> 	cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);
>
> doesn't overwrite some unrelated ranges?
>
> Also, in your example:
>
> * First case:
>
>          leaf 0x0
> 	   leaf 0x1
> 	   leaf 0x2     <- Old max CPUID
> 	   leaf 0x3
> 	   leaf 0x4
> 	   leaf 0x5
> 	   leaf 0x6
> 	   leaf 0x7
> 	   leaf 0x9     <- *New* max CPUID
>
> when you rescan and overwrite [2-9], what guarantees that you don't overwrite
> an already set or cleared bit in those new leafs, say in leaf 5?
>
> Neither set_cpu_cap() nor clear_cpu_cap() pay attention to the max base leaf
> value?

Hmmm, that's a valid point.

So, clear_cpu_cap() logs the cleared bits to cpu_caps_cleared[].

Is there a reason why set_cpu_cap(), supposedly its parallel function,
totally ommits cpu_caps_set[]?

If we can track the clear_cpu_cap() bits above, then AFAIK a reliable
solution would be to just re-initialize the whole CPUID table whole sale
and then invoke apply_forced_caps().

Thanks,
Ahmed

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Borislav Petkov]

On Wed, May 13, 2026 at 07:25:23PM +0200, Ahmed S. Darwish wrote:
> If we can track the clear_cpu_cap() bits above, then AFAIK a reliable
> solution would be to just re-initialize the whole CPUID table whole sale
> and then invoke apply_forced_caps().

Maybe... later...

Right now the *only* thing we wanna do *first* is the conversion. Which is
a huuge undertaking in itself.

So please no more unrelated changes and "it would be good to do this and
that." That can be done later.

If we find a bug while doing so then it is very likely an existing bug which
we'll fix immeditely and continue with the conversion.

Once everything has been converted and the dust settles, *then* w can do
improvements ontop.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Ahmed S. Darwish]

On Wed, 13 May 2026, Borislav Petkov wrote:
>
> Maybe... later...
>
> Right now the *only* thing we wanna do *first* is the conversion. Which is
> a huuge undertaking in itself.
>
> So please no more unrelated changes and "it would be good to do this and
> that." That can be done later.
>
> If we find a bug while doing so then it is very likely an existing bug which
> we'll fix immeditely and continue with the conversion.
>
> Once everything has been converted and the dust settles, *then* w can do
> improvements ontop.

Sounds good.

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Ahmed S. Darwish]

On Tue, 12 May 2026, Borislav Petkov wrote:
>
> On Tue, May 12, 2026 at 09:12:25AM +0200, Ahmed S. Darwish wrote:
> > So the min_t()'s intent is just to be defensive against hardware surprises.
>
> But when you read l0->max_std_leaf, you always get the current, highest base
> level. So there's nothing to protect against.
>
> Or am I missing something?
>

So, let's imagine the following cases of cached CPUID tables.  The changes
to the new max CPUID are due to MSR writes.

* First case:

           leaf 0x0
	   leaf 0x1
	   leaf 0x2     <- Old max CPUID
	   leaf 0x3
	   leaf 0x4
	   leaf 0x5
	   leaf 0x6
	   leaf 0x7
	   leaf 0x9     <- *New* max CPUID

=> Here, the parser code needs to leave CPUID(0x0) and CPUID(0x1) untouched.

That's especially true since CPUID(0x1) holds the backing for some
X86_FEATURE words, other flags might be force set or unset, etc.  So we
don't need to touch that not to corrupt the state of force-enabled or
disabled X86_FEATURE bits.

(Then, it needs to fill the table entries for CPUID(0x3) to CPUID(0x9), but
that's obvious.)

This is accomplished the logic:

	rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
	cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);

Since it will only begin filling things from CPUID(0x3).

* Second case:

           leaf 0x0
	   leaf 0x1
	   leaf 0x2     <- *New* max CPUID
	   leaf 0x3
	   leaf 0x4	<- Old max CPUID

=> Here, the parser will need to zero CPUID(0x3) and CPUID(0x4) entries.

This is because the CPUID API query macros at <asm/cpuid/api.h> know the
validity of each entry through its nr_entries flag:

struct leaf_parse_info {
	unsigned int		nr_entries;
};

And without the zeroing of entries, the CPUID API will return invalid and
stale values for CPUID(0x3) and CPUID(0x4), instead of returning the right
value: NULL.

This is accomplished the logic:

	rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
	cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);

Since it will zero CPUID(0x3) and CPUID(0x4), as it is part of the
cpuid_refresh_range() logic.

And that's what I meant that the min_t() logic handles hardware surprises:
it continues to work, regardless if the new max CPUID is higher or lower
after the MSR write.

I guess I should've put this min_t() logic in its own cpuid_parser.c
function, with proper comments about this.  There were only two cases for
it, this patch and patch 13/90, but two call sites are enough for a parser
API function.

Thanks,
Ahmed

Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Ahmed S. Darwish]

For completeness:

On Wed, 13 May 2026, Ahmed S. Darwish wrote:
>
> * First case:
>
>          leaf 0x0
> 	   leaf 0x1
> 	   leaf 0x2     <- Old max CPUID
> 	   leaf 0x3
> 	   leaf 0x4
> 	   leaf 0x5
> 	   leaf 0x6
> 	   leaf 0x7
> 	   leaf 0x9     <- *New* max CPUID
>
> => Here, the parser code needs to leave CPUID(0x0) and CPUID(0x1) untouched.
>
> That's especially true since CPUID(0x1) holds the backing for some
> X86_FEATURE words, other flags might be force set or unset, etc.  So we
> don't need to touch that not to corrupt the state of force-enabled or
> disabled X86_FEATURE bits.
>
> (Then, it needs to fill the table entries for CPUID(0x3) to CPUID(0x9), but
> that's obvious.)
>
...
>
> * Second case:
>
>          leaf 0x0
> 	   leaf 0x1
> 	   leaf 0x2     <- *New* max CPUID
> 	   leaf 0x3
> 	   leaf 0x4	<- Old max CPUID
>
> => Here, the parser will need to zero CPUID(0x3) and CPUID(0x4) entries.
>
> This is because the CPUID API query macros at <asm/cpuid/api.h> know the
> validity of each entry through its nr_entries flag:
>
> struct leaf_parse_info {
> 	unsigned int		nr_entries;
> };
>
> And without the zeroing of entries, the CPUID API will return invalid and
> stale values for CPUID(0x3) and CPUID(0x4), instead of returning the right
> value: NULL.
>

And similar to the first case, it will also need to keep the previously
cached CPUID(0x1) values intact, not to corrupt any previously force-set or
force-unset bits.

Thanks,
Ahmed