From: Dave Hansen <dave.hansen@linux.intel.com>
The only code that cares about the platform ID is the microcode update
code itself. To facilitate storing the platform ID in a more generic
place and using it outside of the microcode update itself, put the
enumeration into a helper function in a header. Mirror
intel_get_microcode_revision()'s naming and location.
But, moving away from intel_collect_cpu_info() means that the model
and family information in CPUID is not readily available. Just call
CPUID again.
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/microcode.h | 31 +++++++++++++++++++++++++++++++
b/arch/x86/kernel/cpu/microcode/intel.c | 10 +---------
2 files changed, 32 insertions(+), 9 deletions(-)
diff -puN arch/x86/include/asm/microcode.h~refactor-get-processor-flags arch/x86/include/asm/microcode.h
--- a/arch/x86/include/asm/microcode.h~refactor-get-processor-flags 2026-01-19 11:38:08.775892390 -0800
+++ b/arch/x86/include/asm/microcode.h 2026-01-19 11:38:08.783892696 -0800
@@ -2,7 +2,9 @@
#ifndef _ASM_X86_MICROCODE_H
#define _ASM_X86_MICROCODE_H
+#include <asm/cpu.h>
#include <asm/msr.h>
+#include <asm/intel-family.h>
struct cpu_signature {
unsigned int sig;
@@ -75,6 +77,35 @@ static inline u32 intel_get_microcode_re
return rev;
}
+
+/*
+ * Use CPUID to generate a "vfm" value. Useful
+ * before 'cpuinfo_x86' structures are populated.
+ */
+static inline u32 intel_cpuid_vfm(void)
+{
+ u32 eax = cpuid_eax(1);
+ u32 fam = x86_family(eax);
+ u32 model = x86_model(eax);
+
+ return IFM(fam, model);
+}
+
+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);
+}
#endif /* !CONFIG_CPU_SUP_INTEL */
bool microcode_nmi_handler(void);
diff -puN arch/x86/kernel/cpu/microcode/intel.c~refactor-get-processor-flags arch/x86/kernel/cpu/microcode/intel.c
--- a/arch/x86/kernel/cpu/microcode/intel.c~refactor-get-processor-flags 2026-01-19 11:38:08.780892582 -0800
+++ b/arch/x86/kernel/cpu/microcode/intel.c 2026-01-19 11:38:08.783892696 -0800
@@ -123,16 +123,8 @@ static inline unsigned int exttable_size
void intel_collect_cpu_info(struct cpu_signature *sig)
{
sig->sig = cpuid_eax(1);
- sig->pf = 0;
sig->rev = intel_get_microcode_revision();
-
- if (IFM(x86_family(sig->sig), x86_model(sig->sig)) >= INTEL_PENTIUM_III_DESCHUTES) {
- unsigned int val[2];
-
- /* get processor flags from MSR 0x17 */
- native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
- sig->pf = 1 << ((val[1] >> 18) & 7);
- }
+ sig->pf = intel_get_platform_id();
}
EXPORT_SYMBOL_GPL(intel_collect_cpu_info);
_On 1/19/2026 11:50 AM, Dave Hansen wrote:
> +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);
> +}
Would it be better to use a *native_rdmsrq* and proper #defines instead
of passing the two ints and operating on them using magic values?
I understand the desire to keep this bugfix series as minimal as
possible. But doing this now makes it easier to understand this helper
and what it is returning exactly. That would avoid the confusion in
patch 4 between x86_platform_id and platform_mask.
If you prefer to leave the helper as-is, at a minimum, should we rename
it to intel_get_platform_mask()? Also, the variable name in struct
cpuinfo_x86 should then be x86_platform_mask.
> #endif /* !CONFIG_CPU_SUP_INTEL */
>
> bool microcode_nmi_handler(void);
> diff -puN arch/x86/kernel/cpu/microcode/intel.c~refactor-get-processor-flags arch/x86/kernel/cpu/microcode/intel.c
> --- a/arch/x86/kernel/cpu/microcode/intel.c~refactor-get-processor-flags 2026-01-19 11:38:08.780892582 -0800
> +++ b/arch/x86/kernel/cpu/microcode/intel.c 2026-01-19 11:38:08.783892696 -0800
> @@ -123,16 +123,8 @@ static inline unsigned int exttable_size
> void intel_collect_cpu_info(struct cpu_signature *sig)
> {
> sig->sig = cpuid_eax(1);
> - sig->pf = 0;
> sig->rev = intel_get_microcode_revision();
> -
> - if (IFM(x86_family(sig->sig), x86_model(sig->sig)) >= INTEL_PENTIUM_III_DESCHUTES) {
> - unsigned int val[2];
> -
> - /* get processor flags from MSR 0x17 */
> - native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
> - sig->pf = 1 << ((val[1] >> 18) & 7);
> - }
> + sig->pf = intel_get_platform_id();
> }
> EXPORT_SYMBOL_GPL(intel_collect_cpu_info);
>
> _
On Mon, Jan 19, 2026 at 11:50:53AM -0800, Dave Hansen wrote: > >From: Dave Hansen <dave.hansen@linux.intel.com> > >The only code that cares about the platform ID is the microcode update >code itself. To facilitate storing the platform ID in a more generic >place and using it outside of the microcode update itself, put the >enumeration into a helper function in a header. Mirror >intel_get_microcode_revision()'s naming and location. > >But, moving away from intel_collect_cpu_info() means that the model >and family information in CPUID is not readily available. Just call >CPUID again. > >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/microcode.h | 31 +++++++++++++++++++++++++++++++ > b/arch/x86/kernel/cpu/microcode/intel.c | 10 +--------- > 2 files changed, 32 insertions(+), 9 deletions(-) > >diff -puN arch/x86/include/asm/microcode.h~refactor-get-processor-flags arch/x86/include/asm/microcode.h >--- a/arch/x86/include/asm/microcode.h~refactor-get-processor-flags 2026-01-19 11:38:08.775892390 -0800 >+++ b/arch/x86/include/asm/microcode.h 2026-01-19 11:38:08.783892696 -0800 >@@ -2,7 +2,9 @@ > #ifndef _ASM_X86_MICROCODE_H > #define _ASM_X86_MICROCODE_H > >+#include <asm/cpu.h> > #include <asm/msr.h> >+#include <asm/intel-family.h> nit: You may want to sort the header files alphabetically.
On 1/19/26 19:07, Chao Gao wrote: ... >> +#include <asm/cpu.h> >> #include <asm/msr.h> >> +#include <asm/intel-family.h> > nit: You may want to sort the header files alphabetically. I was probably going for christmas tree here or something. But, seriously, I don't think we've written down any guidance on header ordering for tip or in the tree in general. It's still kinda the wild west, I think.
On Tue, Jan 20, 2026 at 08:06:41AM -0800, Dave Hansen wrote: > On 1/19/26 19:07, Chao Gao wrote: ... > >> +#include <asm/cpu.h> > >> #include <asm/msr.h> > >> +#include <asm/intel-family.h> > > nit: You may want to sort the header files alphabetically. > > I was probably going for christmas tree here or something. But, > seriously, I don't think we've written down any guidance on header > ordering for tip or in the tree in general. > > It's still kinda the wild west, I think. It was unclear why you put these two new headers in such an order. Because it feels like you wanted something like alphabetical, but something went differently. For the xmas tree I would expect them still go together #include <asm/msr.h> #include <asm/cpu.h> #include <asm/intel-family.h> But personally I'm with Chao Gao, the alphabetical is easier to maintain as it's natural order that many people got for many years starting from kindergarten times. -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.