From: Dave Hansen <dave.hansen@linux.intel.com>
The end goal here is to be able to do x86_match_cpu() and match on a
specific platform ID. While it would be possible to stash this ID
off somewhere or read it dynamically, that approaches would not be
consistent with the other fields which can be matched.
Read the platform ID and store it in cpuinfo_x86->x86_platform_id.
There are lots of sites to set this new field. Place it near
the place c->microcode is established since the platform ID is
so closely intertwined with microcode updates.
Note: This should not grow the size of 'struct cpuinfo_x86' in
practice since the u8 fits next to another u8 in the structure.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Thomas Gleixner <tglx@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: x86@kernel.org
Cc: Jon Kohler <jon@nutanix.com>
---
b/arch/x86/include/asm/processor.h | 1 +
b/arch/x86/kernel/cpu/common.c | 4 +++-
b/arch/x86/kernel/cpu/intel.c | 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
diff -puN arch/x86/include/asm/processor.h~cpu-x86_stepping arch/x86/include/asm/processor.h
--- a/arch/x86/include/asm/processor.h~cpu-x86_stepping 2026-01-19 11:38:09.341914025 -0800
+++ b/arch/x86/include/asm/processor.h 2026-01-19 11:38:09.444917962 -0800
@@ -140,6 +140,7 @@ struct cpuinfo_x86 {
__u32 x86_vfm;
};
__u8 x86_stepping;
+ __u8 x86_platform_id; /* Intel-only. 3 bits */
#ifdef CONFIG_X86_64
/* Number of 4K pages in DTLB/ITLB combined(in pages): */
int x86_tlbsize;
diff -puN arch/x86/kernel/cpu/common.c~cpu-x86_stepping arch/x86/kernel/cpu/common.c
--- a/arch/x86/kernel/cpu/common.c~cpu-x86_stepping 2026-01-19 11:38:09.428917350 -0800
+++ b/arch/x86/kernel/cpu/common.c 2026-01-19 11:38:09.445918000 -0800
@@ -1981,7 +1981,9 @@ static void identify_cpu(struct cpuinfo_
c->loops_per_jiffy = loops_per_jiffy;
c->x86_cache_size = 0;
c->x86_vendor = X86_VENDOR_UNKNOWN;
- c->x86_model = c->x86_stepping = 0; /* So far unknown... */
+ c->x86_model = 0;
+ c->x86_stepping = 0;
+ c->x86_platform_id = 0;
c->x86_vendor_id[0] = '\0'; /* Unset */
c->x86_model_id[0] = '\0'; /* Unset */
#ifdef CONFIG_X86_64
diff -puN arch/x86/kernel/cpu/intel.c~cpu-x86_stepping arch/x86/kernel/cpu/intel.c
--- a/arch/x86/kernel/cpu/intel.c~cpu-x86_stepping 2026-01-19 11:38:09.441917848 -0800
+++ b/arch/x86/kernel/cpu/intel.c 2026-01-19 11:38:09.445918000 -0800
@@ -205,6 +205,7 @@ static void early_init_intel(struct cpui
if (c->x86 >= 6 && !cpu_has(c, X86_FEATURE_IA64))
c->microcode = intel_get_microcode_revision();
+ c->x86_platform_id = intel_get_platform_id();
/* Now if any of them are set, check the blacklist and clear the lot */
if ((cpu_has(c, X86_FEATURE_SPEC_CTRL) ||
_On Mon, Jan 19, 2026 at 11:50:55AM -0800, Dave Hansen wrote: > > The end goal here is to be able to do x86_match_cpu() and match on a > specific platform ID. While it would be possible to stash this ID > off somewhere or read it dynamically, that approaches would not be > consistent with the other fields which can be matched. > > Read the platform ID and store it in cpuinfo_x86->x86_platform_id. > > There are lots of sites to set this new field. Place it near > the place c->microcode is established since the platform ID is > so closely intertwined with microcode updates. > > Note: This should not grow the size of 'struct cpuinfo_x86' in > practice since the u8 fits next to another u8 in the structure. Have you run `pahole` to confirm? ... > c->x86_cache_size = 0; > c->x86_vendor = X86_VENDOR_UNKNOWN; > - c->x86_model = c->x86_stepping = 0; /* So far unknown... */ Shan't we preserve the comment? /* So far model, stepping, and platform_id are unknown... */ > + c->x86_model = 0; > + c->x86_stepping = 0; > + c->x86_platform_id = 0; > c->x86_vendor_id[0] = '\0'; /* Unset */ > c->x86_model_id[0] = '\0'; /* Unset */ -- With Best Regards, Andy Shevchenko
On 1/20/26 00:27, Andy Shevchenko wrote: ... >> Note: This should not grow the size of 'struct cpuinfo_x86' in >> practice since the u8 fits next to another u8 in the structure. > > Have you run `pahole` to confirm? I have not. If you'd like to contribute to the series by compiling this and running pahole on it, I'd very much appreciate it! > ... > >> c->x86_cache_size = 0; >> c->x86_vendor = X86_VENDOR_UNKNOWN; >> - c->x86_model = c->x86_stepping = 0; /* So far unknown... */ > > Shan't we preserve the comment? > > /* So far model, stepping, and platform_id are unknown... */ ... and cache size and vendor and everything else. It's not a super useful comment.
On Tue, Jan 20, 2026 at 07:06:56AM -0800, Dave Hansen wrote: > On 1/20/26 00:27, Andy Shevchenko wrote: > ... > >> Note: This should not grow the size of 'struct cpuinfo_x86' in > >> practice since the u8 fits next to another u8 in the structure. > > > > Have you run `pahole` to confirm? > > I have not. If you'd like to contribute to the series by compiling this > and running pahole on it, I'd very much appreciate it! Okay, here is the diff: --- old 2026-01-20 21:40:39.170530703 +0100 +++ new 2026-01-20 21:37:42.717138133 +0100 @@ -19,8 +19,9 @@ }; __u8 x86_stepping; /* 4 1 */ + __u8 x86_platform_id; /* 5 1 */ - /* XXX 3 bytes hole, try to pack */ + /* XXX 2 bytes hole, try to pack */ int x86_tlbsize; /* 8 4 */ __u32 vmx_capability[5]; /* 12 20 */ @@ -75,8 +76,8 @@ unsigned int initialized:1; /* 332: 8 4 */ - /* size: 336, cachelines: 6, members: 27 */ - /* sum members: 319, holes: 5, sum holes: 14 */ + /* size: 336, cachelines: 6, members: 28 */ + /* sum members: 320, holes: 5, sum holes: 13 */ /* sum bitfield members: 1 bits (0 bytes) */ /* bit_padding: 23 bits */ /* last cacheline: 16 bytes */ -- With Best Regards, Andy Shevchenko
On 1/20/26 12:44, Andy Shevchenko wrote: > On Tue, Jan 20, 2026 at 07:06:56AM -0800, Dave Hansen wrote: >> On 1/20/26 00:27, Andy Shevchenko wrote: >> ... >>>> Note: This should not grow the size of 'struct cpuinfo_x86' in >>>> practice since the u8 fits next to another u8 in the structure. >>> Have you run `pahole` to confirm? >> I have not. If you'd like to contribute to the series by compiling this >> and running pahole on it, I'd very much appreciate it! > Okay, here is the diff: > > --- old 2026-01-20 21:40:39.170530703 +0100 > +++ new 2026-01-20 21:37:42.717138133 +0100 > @@ -19,8 +19,9 @@ > }; > > __u8 x86_stepping; /* 4 1 */ > + __u8 x86_platform_id; /* 5 1 */ Thanks a lot for verifying that! It appears that my built-in pahole is still working properly! Whew.
On Mon, Jan 19, 2026 at 11:50:55AM -0800, Dave Hansen wrote:
>
>From: Dave Hansen <dave.hansen@linux.intel.com>
>
>The end goal here is to be able to do x86_match_cpu() and match on a
>specific platform ID. While it would be possible to stash this ID
>off somewhere or read it dynamically, that approaches would not be
>consistent with the other fields which can be matched.
>
>Read the platform ID and store it in cpuinfo_x86->x86_platform_id.
>
>There are lots of sites to set this new field. Place it near
>the place c->microcode is established since the platform ID is
>so closely intertwined with microcode updates.
>
>Note: This should not grow the size of 'struct cpuinfo_x86' in
>practice since the u8 fits next to another u8 in the structure.
>
>Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>Cc: Thomas Gleixner <tglx@kernel.org>
>Cc: Ingo Molnar <mingo@redhat.com>
>Cc: Borislav Petkov <bp@alien8.de>
>Cc: Dave Hansen <dave.hansen@linux.intel.com>
>Cc: "H. Peter Anvin" <hpa@zytor.com>
>Cc: Tony Luck <tony.luck@intel.com>
>Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
>Cc: x86@kernel.org
>Cc: Jon Kohler <jon@nutanix.com>
>---
>
> b/arch/x86/include/asm/processor.h | 1 +
> b/arch/x86/kernel/cpu/common.c | 4 +++-
> b/arch/x86/kernel/cpu/intel.c | 1 +
> 3 files changed, 5 insertions(+), 1 deletion(-)
>
>diff -puN arch/x86/include/asm/processor.h~cpu-x86_stepping arch/x86/include/asm/processor.h
>--- a/arch/x86/include/asm/processor.h~cpu-x86_stepping 2026-01-19 11:38:09.341914025 -0800
>+++ b/arch/x86/include/asm/processor.h 2026-01-19 11:38:09.444917962 -0800
>@@ -140,6 +140,7 @@ struct cpuinfo_x86 {
> __u32 x86_vfm;
> };
> __u8 x86_stepping;
>+ __u8 x86_platform_id; /* Intel-only. 3 bits */
Tail comments are not preferred. I've seen tglx complain about them a few times.
Also, "3 bits" is misleading since x86_platform_id actually stores a bit mask.
On 1/19/26 19:14, Chao Gao wrote: >> __u8 x86_stepping; >> + __u8 x86_platform_id; /* Intel-only. 3 bits */ > Tail comments are not preferred. I've seen tglx complain about them a few times. Yeah, you're right. It doesn't fit well with the rest of the structure. I'll fix it. > Also, "3 bits" is misleading since x86_platform_id actually stores a bit mask. Remember, there are two structures in play here. From the cover letter: > Treat the platform ID as a peer of model/family/stepping. Store it > in 'struct cpuinfo_x86', enable matching on it with with 'struct > x86_cpu_id', and flesh out the 'old_microcode' list with it. This hunk is patching 'cpuinfo_x86' which stores the 3 bits explicitly. I think you're thinking of the mask in 'x86_cpu_id' which is used for _matching_ this field in patch 5. Could you double check that you're asking about the right structure, please? I've certainly gotten the two structures mixed up before.
On Tue, Jan 20, 2026 at 07:22:54AM -0800, Dave Hansen wrote:
>On 1/19/26 19:14, Chao Gao wrote:
>>> __u8 x86_stepping;
>>> + __u8 x86_platform_id; /* Intel-only. 3 bits */
>> Tail comments are not preferred. I've seen tglx complain about them a few times.
>
>Yeah, you're right. It doesn't fit well with the rest of the structure.
>I'll fix it.
>
>> Also, "3 bits" is misleading since x86_platform_id actually stores a bit mask.
>
>Remember, there are two structures in play here. From the cover letter:
>
>> Treat the platform ID as a peer of model/family/stepping. Store it
>> in 'struct cpuinfo_x86', enable matching on it with with 'struct
>> x86_cpu_id', and flesh out the 'old_microcode' list with it.
>
>This hunk is patching 'cpuinfo_x86' which stores the 3 bits explicitly.
Hi Dave,
This patch has:
c->x86_platform_id = intel_get_platform_id();
but intel_get_platform_id() doesn't return the 3 bits; it returns a
single-bit mask (or 0 on old CPUs).
+static inline u32 intel_get_platform_id(void)
+{
+ unsigned int val[2];
+
+ /*
+ * This can be called early. Use CPUID directly to
+ * generate the VFM value for this CPU.
+ */
+ if (intel_cpuid_vfm() < INTEL_PENTIUM_III_DESCHUTES)
+ return 0;
+
+ /* get processor flags from MSR 0x17 */
+ native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
+ return 1 << ((val[1] >> 18) & 7);
+}
>
>I think you're thinking of the mask in 'x86_cpu_id' which is used for
>_matching_ this field in patch 5.
>
>Could you double check that you're asking about the right structure,
>please? I've certainly gotten the two structures mixed up before.
© 2016 - 2026 Red Hat, Inc.