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