* [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks
@ 2026-02-06 23:14 Dave Hansen
2026-02-06 23:14 ` [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header Dave Hansen
` (6 more replies)
0 siblings, 7 replies; 37+ messages in thread
From: Dave Hansen @ 2026-02-06 23:14 UTC (permalink / raw)
To: linux-kernel
Cc: sohil.mehta, zhao1.liu, Dave Hansen, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
Changes from v1:
* Fix non-x86 PECI compile issues by lifting some x86 macros
into an arch-independent header.
* Make intel_get_platform_id() match its name and return an ID,
not a mask.
* Sort #includes
* Move ->x86_platform_id comment
The platform ID vs. platform mask confusion meant that v1
worked by total accident. If you tested v1, I'd really
appreciate you retest this as well.
--
There was a report[1] that CPUs running updated microcode were being
reported as running old microcode. The reason is that the old
microcode list neglects to take the platform ID into account.
The platform ID is an Intel-only construct that allows CPUs that
otherwise have the same model/family/stepping to take different
microcode revisions. The microcode loader itself already checks this.
Only the recent "old_microcode" checker failed here.
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 fixes the report of an inaccurate, false positive in the
'old_microcode' vulnerability file.
1. https://lore.kernel.org/all/38660F8F-499E-48CD-B58B-4822228A5941@nutanix.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>
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-06 23:14 [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen
@ 2026-02-06 23:14 ` Dave Hansen
2026-02-10 22:13 ` Sohil Mehta
2026-02-06 23:14 ` [PATCH 2/6] x86/cpu: Add missing #include Dave Hansen
` (5 subsequent siblings)
6 siblings, 1 reply; 37+ messages in thread
From: Dave Hansen @ 2026-02-06 23:14 UTC (permalink / raw)
To: linux-kernel
Cc: sohil.mehta, zhao1.liu, Dave Hansen, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
From: Dave Hansen <dave.hansen@linux.intel.com>
The intel-family.h header uses Vendor/Family/Model macros but it does not
#include the header where they are defined. If that header is included,
the build blows up in #include hell.
Luckily, these macros are completely independent and do not themselves
have any dependencies on other code.
Break the VFM_*() macros out into their own header.
Note that the new header is in asm-generic. Believe it or not, the
intel-family.h header is included from a driver in arch-generic code:
#include "../../arch/x86/include/asm/intel-family.h"
Putting the header in generic code will move in the right direction
of reducing the amount of code that the "peci" driver needs to copy.
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/cpu_device_id.h | 33 ----------------------------
b/include/asm-generic/x86-vfm.h | 38 +++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 32 deletions(-)
diff -puN arch/x86/include/asm/cpu_device_id.h~x86-vfm_h arch/x86/include/asm/cpu_device_id.h
--- a/arch/x86/include/asm/cpu_device_id.h~x86-vfm_h 2026-02-06 15:14:21.848731168 -0800
+++ b/arch/x86/include/asm/cpu_device_id.h 2026-02-06 15:14:21.851731274 -0800
@@ -2,38 +2,7 @@
#ifndef _ASM_X86_CPU_DEVICE_ID
#define _ASM_X86_CPU_DEVICE_ID
-/*
- * Can't use <linux/bitfield.h> because it generates expressions that
- * cannot be used in structure initializers. Bitfield construction
- * here must match the union in struct cpuinfo_86:
- * union {
- * struct {
- * __u8 x86_model;
- * __u8 x86;
- * __u8 x86_vendor;
- * __u8 x86_reserved;
- * };
- * __u32 x86_vfm;
- * };
- */
-#define VFM_MODEL_BIT 0
-#define VFM_FAMILY_BIT 8
-#define VFM_VENDOR_BIT 16
-#define VFM_RSVD_BIT 24
-
-#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
-#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
-#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
-
-#define VFM_MODEL(vfm) (((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT)
-#define VFM_FAMILY(vfm) (((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT)
-#define VFM_VENDOR(vfm) (((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT)
-
-#define VFM_MAKE(_vendor, _family, _model) ( \
- ((_model) << VFM_MODEL_BIT) | \
- ((_family) << VFM_FAMILY_BIT) | \
- ((_vendor) << VFM_VENDOR_BIT) \
-)
+#include <asm-generic/x86-vfm.h>
/*
* Declare drivers belonging to specific x86 CPUs
diff -puN /dev/null include/asm-generic/x86-vfm.h
--- /dev/null 2026-01-31 18:22:27.334169132 -0800
+++ b/include/asm-generic/x86-vfm.h 2026-02-06 15:14:21.851731274 -0800
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_GENERIC_X86_VFM
+#define _ASM_GENERIC_X86_VFM
+
+/*
+ * Can't use <linux/bitfield.h> because it generates expressions that
+ * cannot be used in structure initializers. Bitfield construction
+ * here must match the union in struct cpuinfo_86:
+ * union {
+ * struct {
+ * __u8 x86_model;
+ * __u8 x86;
+ * __u8 x86_vendor;
+ * __u8 x86_reserved;
+ * };
+ * __u32 x86_vfm;
+ * };
+ */
+#define VFM_MODEL_BIT 0
+#define VFM_FAMILY_BIT 8
+#define VFM_VENDOR_BIT 16
+#define VFM_RSVD_BIT 24
+
+#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
+#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
+#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
+
+#define VFM_MODEL(vfm) (((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT)
+#define VFM_FAMILY(vfm) (((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT)
+#define VFM_VENDOR(vfm) (((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT)
+
+#define VFM_MAKE(_vendor, _family, _model) ( \
+ ((_model) << VFM_MODEL_BIT) | \
+ ((_family) << VFM_FAMILY_BIT) | \
+ ((_vendor) << VFM_VENDOR_BIT) \
+)
+
+#endif /* _ASM_GENERIC_X86_VFM */
_
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 2/6] x86/cpu: Add missing #include
2026-02-06 23:14 [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen
2026-02-06 23:14 ` [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header Dave Hansen
@ 2026-02-06 23:14 ` Dave Hansen
2026-02-06 23:14 ` [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper Dave Hansen
` (4 subsequent siblings)
6 siblings, 0 replies; 37+ messages in thread
From: Dave Hansen @ 2026-02-06 23:14 UTC (permalink / raw)
To: linux-kernel
Cc: sohil.mehta, zhao1.liu, Dave Hansen, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
From: Dave Hansen <dave.hansen@linux.intel.com>
The intel-family.h header uses Vendor/Family/Model macros but it does
not #include the header where they are defined. It must be depending
on implicit includes.
Include the required header explicitly.
Note that having this code in an explicitly #include'd header, non-x86
header means that the PECI code can zap its copy. Do that as well.
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/intel-family.h | 7 +++++++
b/include/linux/peci-cpu.h | 20 --------------------
2 files changed, 7 insertions(+), 20 deletions(-)
diff -puN arch/x86/include/asm/intel-family.h~fam-missing-include arch/x86/include/asm/intel-family.h
--- a/arch/x86/include/asm/intel-family.h~fam-missing-include 2026-02-06 15:14:22.380749864 -0800
+++ b/arch/x86/include/asm/intel-family.h 2026-02-06 15:14:22.387750111 -0800
@@ -3,6 +3,13 @@
#define _ASM_X86_INTEL_FAMILY_H
/*
+ * Note: despite being in arch/x86, the PECI driver(s) use
+ * this header in arch-independent drivers. Do not use
+ * any x86-specific headers here:
+ */
+#include <asm-generic/x86-vfm.h>
+
+/*
* "Big Core" Processors (Branded as Core, Xeon, etc...)
*
* While adding a new CPUID for a new microarchitecture, add a new
diff -puN include/linux/peci-cpu.h~fam-missing-include include/linux/peci-cpu.h
--- a/include/linux/peci-cpu.h~fam-missing-include 2026-02-06 15:14:22.383749970 -0800
+++ b/include/linux/peci-cpu.h 2026-02-06 15:14:22.387750111 -0800
@@ -8,26 +8,6 @@
/* Copied from x86 <asm/processor.h> */
#define X86_VENDOR_INTEL 0
-
-/* Copied from x86 <asm/cpu_device_id.h> */
-#define VFM_MODEL_BIT 0
-#define VFM_FAMILY_BIT 8
-#define VFM_VENDOR_BIT 16
-#define VFM_RSVD_BIT 24
-
-#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
-#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
-#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
-
-#define VFM_MODEL(vfm) (((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT)
-#define VFM_FAMILY(vfm) (((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT)
-#define VFM_VENDOR(vfm) (((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT)
-
-#define VFM_MAKE(_vendor, _family, _model) ( \
- ((_model) << VFM_MODEL_BIT) | \
- ((_family) << VFM_FAMILY_BIT) | \
- ((_vendor) << VFM_VENDOR_BIT) \
-)
/* End of copied code */
#include "../../arch/x86/include/asm/intel-family.h"
_
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper
2026-02-06 23:14 [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen
2026-02-06 23:14 ` [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header Dave Hansen
2026-02-06 23:14 ` [PATCH 2/6] x86/cpu: Add missing #include Dave Hansen
@ 2026-02-06 23:14 ` Dave Hansen
2026-02-10 23:20 ` Sohil Mehta
2026-02-06 23:14 ` [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen
` (3 subsequent siblings)
6 siblings, 1 reply; 37+ messages in thread
From: Dave Hansen @ 2026-02-06 23:14 UTC (permalink / raw)
To: linux-kernel
Cc: sohil.mehta, zhao1.liu, Dave Hansen, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
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.
Note that the microcode header is a mask of supported platform IDs.
Only stick the ID part in the helper. Leave the 1<<id part in the
microcode handling.
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 | 32 ++++++++++++++++++++++++++++++++
b/arch/x86/kernel/cpu/microcode/intel.c | 10 +---------
2 files changed, 33 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-02-06 15:14:22.932769264 -0800
+++ b/arch/x86/include/asm/microcode.h 2026-02-06 15:14:22.989771267 -0800
@@ -2,6 +2,8 @@
#ifndef _ASM_X86_MICROCODE_H
#define _ASM_X86_MICROCODE_H
+#include <asm/cpu.h>
+#include <asm/intel-family.h>
#include <asm/msr.h>
struct cpu_signature {
@@ -75,6 +77,36 @@ 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 (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-02-06 15:14:22.987771197 -0800
+++ b/arch/x86/kernel/cpu/microcode/intel.c 2026-02-06 15:14:22.989771267 -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 = 1 << intel_get_platform_id();
}
EXPORT_SYMBOL_GPL(intel_collect_cpu_info);
_
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure
2026-02-06 23:14 [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen
` (2 preceding siblings ...)
2026-02-06 23:14 ` [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper Dave Hansen
@ 2026-02-06 23:14 ` Dave Hansen
2026-02-08 21:37 ` Borislav Petkov
2026-02-10 23:23 ` Sohil Mehta
2026-02-06 23:14 ` [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure Dave Hansen
` (2 subsequent siblings)
6 siblings, 2 replies; 37+ messages in thread
From: Dave Hansen @ 2026-02-06 23:14 UTC (permalink / raw)
To: linux-kernel
Cc: sohil.mehta, zhao1.liu, Dave Hansen, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
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 | 2 ++
b/arch/x86/kernel/cpu/common.c | 4 +++-
b/arch/x86/kernel/cpu/intel.c | 1 +
3 files changed, 6 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-02-06 15:14:23.528790212 -0800
+++ b/arch/x86/include/asm/processor.h 2026-02-06 15:14:23.567791582 -0800
@@ -140,6 +140,8 @@ struct cpuinfo_x86 {
__u32 x86_vfm;
};
__u8 x86_stepping;
+ /* Intel-only. 3 bits: */
+ __u8 x86_platform_id;
#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-02-06 15:14:23.552791055 -0800
+++ b/arch/x86/kernel/cpu/common.c 2026-02-06 15:14:23.568791618 -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-02-06 15:14:23.564791477 -0800
+++ b/arch/x86/kernel/cpu/intel.c 2026-02-06 15:14:23.568791618 -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) ||
_
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure
2026-02-06 23:14 [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen
` (3 preceding siblings ...)
2026-02-06 23:14 ` [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen
@ 2026-02-06 23:14 ` Dave Hansen
2026-02-10 23:27 ` Sohil Mehta
2026-02-06 23:14 ` [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list Dave Hansen
2026-02-09 10:20 ` [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Maciej Wieczor-Retman
6 siblings, 1 reply; 37+ messages in thread
From: Dave Hansen @ 2026-02-06 23:14 UTC (permalink / raw)
To: linux-kernel
Cc: sohil.mehta, zhao1.liu, Dave Hansen, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
From: Dave Hansen <dave.hansen@linux.intel.com>
The existing x86_match_cpu() infrastructure can be used to match
a bunch of attributes of a CPU: vendor, family, model, steppings
and CPU features.
But, there's one more attribute that's missing and unable to be
matched against: the platform ID, enumerated on Intel CPUs in
MSR_IA32_PLATFORM_ID. It is a little more obscure and is only
queried during microcode loading. This is because Intel sometimes
has CPUs with identical family/model/stepping but which need
different microcode. These CPUs are differentiated with the
platform ID.
Add a field in 'struct x86_cpu_id' for the platform ID. Similar
to the stepping field, make the new field a mask of platform IDs.
Some examples:
0x01: matches only platform ID 0x0
0x02: matches only platform ID 0x1
0x03: matches platform IDs 0x0 or 0x1
0x80: matches only platform ID 0x7
0xff: matches all 8 possible platform IDs
Since the mask is only a byte wide, it nestles in next to another
u8 and does not even increase the size of 'struct x86_cpu_id'.
Reserve the all 0's value as the wildcard (X86_PLATFORM_ANY). This
avoids forcing changes changes to existing 'struct x86_cpu_id' users.
They can just continue to fill the field with 0's and their matching
will work exactly as before.
Note: If someone is ever looking for space in 'struct x86_cpu_id',
this new field could probably get stuck over in ->driver_data
for the one user that there is.
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/kernel/cpu/match.c | 3 +++
b/include/linux/mod_devicetable.h | 2 ++
2 files changed, 5 insertions(+)
diff -puN arch/x86/kernel/cpu/match.c~platform-match arch/x86/kernel/cpu/match.c
--- a/arch/x86/kernel/cpu/match.c~platform-match 2026-02-06 15:14:24.127811266 -0800
+++ b/arch/x86/kernel/cpu/match.c 2026-02-06 15:14:24.137811618 -0800
@@ -76,6 +76,9 @@ const struct x86_cpu_id *x86_match_cpu(c
if (m->steppings != X86_STEPPING_ANY &&
!(BIT(c->x86_stepping) & m->steppings))
continue;
+ if (m->platform_mask != X86_PLATFORM_ANY &&
+ !(BIT(c->x86_platform_id) & m->platform_mask))
+ continue;
if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
continue;
if (!x86_match_vendor_cpu_type(c, m))
diff -puN include/linux/mod_devicetable.h~platform-match include/linux/mod_devicetable.h
--- a/include/linux/mod_devicetable.h~platform-match 2026-02-06 15:14:24.134811512 -0800
+++ b/include/linux/mod_devicetable.h 2026-02-06 15:14:24.137811618 -0800
@@ -692,6 +692,7 @@ struct x86_cpu_id {
__u16 feature; /* bit index */
/* Solely for kernel-internal use: DO NOT EXPORT to userspace! */
__u16 flags;
+ __u8 platform_mask;
__u8 type;
kernel_ulong_t driver_data;
};
@@ -703,6 +704,7 @@ struct x86_cpu_id {
#define X86_STEPPING_ANY 0
#define X86_STEP_MIN 0
#define X86_STEP_MAX 0xf
+#define X86_PLATFORM_ANY 0x0
#define X86_FEATURE_ANY 0 /* Same as FPU, you can't test for that */
#define X86_CPU_TYPE_ANY 0
_
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list
2026-02-06 23:14 [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen
` (4 preceding siblings ...)
2026-02-06 23:14 ` [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure Dave Hansen
@ 2026-02-06 23:14 ` Dave Hansen
2026-02-10 23:39 ` Sohil Mehta
2026-02-09 10:20 ` [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Maciej Wieczor-Retman
6 siblings, 1 reply; 37+ messages in thread
From: Dave Hansen @ 2026-02-06 23:14 UTC (permalink / raw)
To: linux-kernel
Cc: sohil.mehta, zhao1.liu, Dave Hansen, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
From: Dave Hansen <dave.hansen@linux.intel.com>
Intel sometimes has CPUs with identical family/model/stepping but
which need different microcode. These CPUs are differentiated with the
platform ID.
The Intel "microcode-20250512" release was used to generate the
existing contents of intel-ucode-defs.h. Use that same release and add
the platform mask to the definitions.
This makes the list a few entries longer. For example for the ancient
Pentium III there are two CPUs that differ only in their platform and
have two different microcode versions:
{ ..., .model = 0x05, .steppings = 0x0001, .platform_mask = 0x01, .driver_data = 0x40 },
{ ..., .model = 0x05, .steppings = 0x0001, .platform_mask = 0x08, .driver_data = 0x45 },
These CPUs previously shared a definition. Another example is the
state-of-the-art Granite Rapids:
{ ..., .model = 0xad, .steppings = 0x0002, .platform_mask = 0x20, .driver_data = 0xa0000d1 },
{ ..., .model = 0xad, .steppings = 0x0002, .platform_mask = 0x95, .driver_data = 0x10003a2 },
As you can see, this differentiation with platform ID has been
necessary for a long time and is still relevant today.
Without the platform matching, the old microcode table is incomplete.
For instance, it might lead someone with a Pentium III, platform 0x0,
and microcode 0x40 to think that they should have microcode 0x45,
which is really only for platform 0x4 (.platform_mask==0x08).
In practice, this meant that folks with fully updated microcode were
seeing "Vulnerable" in the "old_microcode" file.
1. https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reported-by: Jon Kohler <jon@nutanix.com>
Fixes: 4e2c719782a8 ("x86/cpu: Help users notice when running old Intel microcode")
Tested-by: Zhao Liu <zhao1.liu@intel.com>
Link: https://lore.kernel.org/all/3ECBB974-C6F0-47A7-94B6-3646347F1CC2@nutanix.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
---
b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h | 398 ++++++++++++---------
1 file changed, 238 insertions(+), 160 deletions(-)
diff -puN arch/x86/kernel/cpu/microcode/intel-ucode-defs.h~add-platform-to-defs arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
--- a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h~add-platform-to-defs 2026-02-06 15:14:24.695831233 -0800
+++ b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h 2026-02-06 15:14:24.699831374 -0800
@@ -1,160 +1,238 @@
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x03, .steppings = 0x0004, .driver_data = 0x2 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0001, .driver_data = 0x45 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0002, .driver_data = 0x40 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0004, .driver_data = 0x2c },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0008, .driver_data = 0x10 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x0001, .driver_data = 0xa },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x0020, .driver_data = 0x3 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x0400, .driver_data = 0xd },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x2000, .driver_data = 0x7 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x07, .steppings = 0x0002, .driver_data = 0x14 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x07, .steppings = 0x0004, .driver_data = 0x38 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x07, .steppings = 0x0008, .driver_data = 0x2e },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0002, .driver_data = 0x11 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0008, .driver_data = 0x8 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0040, .driver_data = 0xc },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0400, .driver_data = 0x5 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x09, .steppings = 0x0020, .driver_data = 0x47 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0a, .steppings = 0x0001, .driver_data = 0x3 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0a, .steppings = 0x0002, .driver_data = 0x1 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0b, .steppings = 0x0002, .driver_data = 0x1d },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0b, .steppings = 0x0010, .driver_data = 0x2 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0d, .steppings = 0x0040, .driver_data = 0x18 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0e, .steppings = 0x0100, .driver_data = 0x39 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0e, .steppings = 0x1000, .driver_data = 0x59 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0004, .driver_data = 0x5d },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0040, .driver_data = 0xd2 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0080, .driver_data = 0x6b },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0400, .driver_data = 0x95 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0800, .driver_data = 0xbc },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x2000, .driver_data = 0xa4 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x16, .steppings = 0x0002, .driver_data = 0x44 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0040, .driver_data = 0x60f },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0080, .driver_data = 0x70a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0400, .driver_data = 0xa0b },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1a, .steppings = 0x0010, .driver_data = 0x12 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1a, .steppings = 0x0020, .driver_data = 0x1d },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1c, .steppings = 0x0004, .driver_data = 0x219 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1c, .steppings = 0x0400, .driver_data = 0x107 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1d, .steppings = 0x0002, .driver_data = 0x29 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1e, .steppings = 0x0020, .driver_data = 0xa },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x25, .steppings = 0x0004, .driver_data = 0x11 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x25, .steppings = 0x0020, .driver_data = 0x7 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x26, .steppings = 0x0002, .driver_data = 0x105 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2a, .steppings = 0x0080, .driver_data = 0x2f },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2c, .steppings = 0x0004, .driver_data = 0x1f },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2d, .steppings = 0x0040, .driver_data = 0x621 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2d, .steppings = 0x0080, .driver_data = 0x71a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2e, .steppings = 0x0040, .driver_data = 0xd },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2f, .steppings = 0x0004, .driver_data = 0x3b },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x37, .steppings = 0x0100, .driver_data = 0x838 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x37, .steppings = 0x0200, .driver_data = 0x90d },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3a, .steppings = 0x0200, .driver_data = 0x21 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3c, .steppings = 0x0008, .driver_data = 0x28 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3d, .steppings = 0x0010, .driver_data = 0x2f },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3e, .steppings = 0x0010, .driver_data = 0x42e },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3e, .steppings = 0x0040, .driver_data = 0x600 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3e, .steppings = 0x0080, .driver_data = 0x715 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3f, .steppings = 0x0004, .driver_data = 0x49 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3f, .steppings = 0x0010, .driver_data = 0x1a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x45, .steppings = 0x0002, .driver_data = 0x26 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x46, .steppings = 0x0002, .driver_data = 0x1c },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x47, .steppings = 0x0002, .driver_data = 0x22 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x4c, .steppings = 0x0008, .driver_data = 0x368 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x4c, .steppings = 0x0010, .driver_data = 0x411 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x4d, .steppings = 0x0100, .driver_data = 0x12d },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x4e, .steppings = 0x0008, .driver_data = 0xf0 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0008, .driver_data = 0x1000191 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0010, .driver_data = 0x2007006 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0020, .driver_data = 0x3000010 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0080, .driver_data = 0x5003901 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0800, .driver_data = 0x7002b01 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x56, .steppings = 0x0004, .driver_data = 0x1c },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x56, .steppings = 0x0008, .driver_data = 0x700001c },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x56, .steppings = 0x0010, .driver_data = 0xf00001a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x56, .steppings = 0x0020, .driver_data = 0xe000015 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x5c, .steppings = 0x0004, .driver_data = 0x14 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x5c, .steppings = 0x0200, .driver_data = 0x48 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x5c, .steppings = 0x0400, .driver_data = 0x28 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x5e, .steppings = 0x0008, .driver_data = 0xf0 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x5f, .steppings = 0x0002, .driver_data = 0x3e },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x66, .steppings = 0x0008, .driver_data = 0x2a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x6a, .steppings = 0x0020, .driver_data = 0xc0002f0 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x6a, .steppings = 0x0040, .driver_data = 0xd000404 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x6c, .steppings = 0x0002, .driver_data = 0x10002d0 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7a, .steppings = 0x0002, .driver_data = 0x42 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7a, .steppings = 0x0100, .driver_data = 0x26 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7e, .steppings = 0x0020, .driver_data = 0xca },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8a, .steppings = 0x0002, .driver_data = 0x33 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8c, .steppings = 0x0002, .driver_data = 0xbc },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8c, .steppings = 0x0004, .driver_data = 0x3c },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8d, .steppings = 0x0002, .driver_data = 0x56 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8e, .steppings = 0x0200, .driver_data = 0xf6 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8e, .steppings = 0x0400, .driver_data = 0xf6 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8e, .steppings = 0x0800, .driver_data = 0xf6 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8e, .steppings = 0x1000, .driver_data = 0x100 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0010, .driver_data = 0x2c0003f7 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0020, .driver_data = 0x2c0003f7 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0040, .driver_data = 0x2c0003f7 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0080, .driver_data = 0x2b000639 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0100, .driver_data = 0x2c0003f7 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x96, .steppings = 0x0002, .driver_data = 0x1a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x97, .steppings = 0x0004, .driver_data = 0x3a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x97, .steppings = 0x0020, .driver_data = 0x3a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9a, .steppings = 0x0008, .driver_data = 0x437 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9a, .steppings = 0x0010, .driver_data = 0x437 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9c, .steppings = 0x0001, .driver_data = 0x24000026 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9e, .steppings = 0x0200, .driver_data = 0xf8 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9e, .steppings = 0x0400, .driver_data = 0xfa },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9e, .steppings = 0x0800, .driver_data = 0xf6 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9e, .steppings = 0x1000, .driver_data = 0xf8 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9e, .steppings = 0x2000, .driver_data = 0x104 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa5, .steppings = 0x0004, .driver_data = 0x100 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa5, .steppings = 0x0008, .driver_data = 0x100 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa5, .steppings = 0x0020, .driver_data = 0x100 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa6, .steppings = 0x0001, .driver_data = 0x102 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa6, .steppings = 0x0002, .driver_data = 0x100 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa7, .steppings = 0x0002, .driver_data = 0x64 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xaa, .steppings = 0x0010, .driver_data = 0x24 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xad, .steppings = 0x0002, .driver_data = 0xa0000d1 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xaf, .steppings = 0x0008, .driver_data = 0x3000341 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xb5, .steppings = 0x0001, .driver_data = 0xa },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xb7, .steppings = 0x0002, .driver_data = 0x12f },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xb7, .steppings = 0x0010, .driver_data = 0x12f },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xba, .steppings = 0x0004, .driver_data = 0x4128 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xba, .steppings = 0x0008, .driver_data = 0x4128 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xba, .steppings = 0x0100, .driver_data = 0x4128 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbd, .steppings = 0x0002, .driver_data = 0x11f },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbe, .steppings = 0x0001, .driver_data = 0x1d },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbf, .steppings = 0x0004, .driver_data = 0x3a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbf, .steppings = 0x0020, .driver_data = 0x3a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbf, .steppings = 0x0040, .driver_data = 0x3a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbf, .steppings = 0x0080, .driver_data = 0x3a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xc5, .steppings = 0x0004, .driver_data = 0x118 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xc6, .steppings = 0x0004, .driver_data = 0x118 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xc6, .steppings = 0x0010, .driver_data = 0x118 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xca, .steppings = 0x0004, .driver_data = 0x118 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xcf, .steppings = 0x0002, .driver_data = 0x210002a9 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xcf, .steppings = 0x0004, .driver_data = 0x210002a9 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x00, .steppings = 0x0080, .driver_data = 0x12 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x00, .steppings = 0x0400, .driver_data = 0x15 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x01, .steppings = 0x0004, .driver_data = 0x2e },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0010, .driver_data = 0x21 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0020, .driver_data = 0x2c },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0040, .driver_data = 0x10 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0080, .driver_data = 0x39 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0200, .driver_data = 0x2f },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x03, .steppings = 0x0004, .driver_data = 0xa },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x03, .steppings = 0x0008, .driver_data = 0xc },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x03, .steppings = 0x0010, .driver_data = 0x17 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0002, .driver_data = 0x17 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0008, .driver_data = 0x5 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0010, .driver_data = 0x6 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0080, .driver_data = 0x3 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0100, .driver_data = 0xe },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0200, .driver_data = 0x3 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0400, .driver_data = 0x4 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x06, .steppings = 0x0004, .driver_data = 0xf },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x06, .steppings = 0x0010, .driver_data = 0x4 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x06, .steppings = 0x0020, .driver_data = 0x8 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x06, .steppings = 0x0100, .driver_data = 0x9 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x03, .steppings = 0x0004, .platform_mask = 0x00, .driver_data = 0x2 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0001, .platform_mask = 0x01, .driver_data = 0x40 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0001, .platform_mask = 0x02, .driver_data = 0x41 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0001, .platform_mask = 0x08, .driver_data = 0x45 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0002, .platform_mask = 0x01, .driver_data = 0x40 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0004, .platform_mask = 0x01, .driver_data = 0x2a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0004, .platform_mask = 0x02, .driver_data = 0x2c },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0004, .platform_mask = 0x04, .driver_data = 0x2b },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0008, .platform_mask = 0x01, .driver_data = 0x10 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0008, .platform_mask = 0x02, .driver_data = 0xc },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0008, .platform_mask = 0x04, .driver_data = 0xb },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x05, .steppings = 0x0008, .platform_mask = 0x08, .driver_data = 0xd },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x0001, .platform_mask = 0x01, .driver_data = 0xa },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x0020, .platform_mask = 0x10, .driver_data = 0x3 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x0400, .platform_mask = 0x02, .driver_data = 0xc },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x0400, .platform_mask = 0x08, .driver_data = 0xd },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x0400, .platform_mask = 0x20, .driver_data = 0xb },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x2000, .platform_mask = 0x02, .driver_data = 0x5 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x2000, .platform_mask = 0x08, .driver_data = 0x6 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x06, .steppings = 0x2000, .platform_mask = 0x20, .driver_data = 0x7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x07, .steppings = 0x0002, .platform_mask = 0x04, .driver_data = 0x14 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x07, .steppings = 0x0004, .platform_mask = 0x04, .driver_data = 0x38 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x07, .steppings = 0x0008, .platform_mask = 0x04, .driver_data = 0x2e },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0002, .platform_mask = 0x01, .driver_data = 0xd },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0002, .platform_mask = 0x04, .driver_data = 0x10 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0002, .platform_mask = 0x08, .driver_data = 0xf },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0002, .platform_mask = 0x10, .driver_data = 0x11 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0002, .platform_mask = 0x20, .driver_data = 0xe },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0008, .platform_mask = 0x08, .driver_data = 0x8 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0008, .platform_mask = 0x20, .driver_data = 0x7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0040, .platform_mask = 0x01, .driver_data = 0x7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0040, .platform_mask = 0x02, .driver_data = 0xa },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0040, .platform_mask = 0x04, .driver_data = 0x2 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0040, .platform_mask = 0x10, .driver_data = 0x8 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0040, .platform_mask = 0x80, .driver_data = 0xc },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0400, .platform_mask = 0x10, .driver_data = 0x1 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0400, .platform_mask = 0x20, .driver_data = 0x4 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x08, .steppings = 0x0400, .platform_mask = 0x80, .driver_data = 0x5 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x09, .steppings = 0x0020, .platform_mask = 0x10, .driver_data = 0x7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x09, .steppings = 0x0020, .platform_mask = 0x20, .driver_data = 0x7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x09, .steppings = 0x0020, .platform_mask = 0x80, .driver_data = 0x47 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0a, .steppings = 0x0001, .platform_mask = 0x04, .driver_data = 0x3 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0a, .steppings = 0x0002, .platform_mask = 0x04, .driver_data = 0x1 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0b, .steppings = 0x0002, .platform_mask = 0x10, .driver_data = 0x1c },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0b, .steppings = 0x0002, .platform_mask = 0x20, .driver_data = 0x1d },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0b, .steppings = 0x0010, .platform_mask = 0x10, .driver_data = 0x1 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0b, .steppings = 0x0010, .platform_mask = 0x20, .driver_data = 0x2 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0d, .steppings = 0x0040, .platform_mask = 0x20, .driver_data = 0x18 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0e, .steppings = 0x0100, .platform_mask = 0x20, .driver_data = 0x39 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0e, .steppings = 0x1000, .platform_mask = 0x20, .driver_data = 0x54 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0e, .steppings = 0x1000, .platform_mask = 0x80, .driver_data = 0x59 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0004, .platform_mask = 0x01, .driver_data = 0x5d },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0004, .platform_mask = 0x20, .driver_data = 0x5c },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0040, .platform_mask = 0x01, .driver_data = 0xd0 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0040, .platform_mask = 0x04, .driver_data = 0xd2 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0040, .platform_mask = 0x20, .driver_data = 0xd1 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0080, .platform_mask = 0x10, .driver_data = 0x6a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0080, .platform_mask = 0x40, .driver_data = 0x6b },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0400, .platform_mask = 0x80, .driver_data = 0x95 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0800, .platform_mask = 0x01, .driver_data = 0xba },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0800, .platform_mask = 0x04, .driver_data = 0xbc },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0800, .platform_mask = 0x08, .driver_data = 0xbb },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0800, .platform_mask = 0x10, .driver_data = 0xba },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0800, .platform_mask = 0x20, .driver_data = 0xba },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0800, .platform_mask = 0x40, .driver_data = 0xbc },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x0800, .platform_mask = 0x80, .driver_data = 0xba },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x2000, .platform_mask = 0x01, .driver_data = 0xa4 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x2000, .platform_mask = 0x20, .driver_data = 0xa4 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x0f, .steppings = 0x2000, .platform_mask = 0x80, .driver_data = 0xa4 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x16, .steppings = 0x0002, .platform_mask = 0x01, .driver_data = 0x43 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x16, .steppings = 0x0002, .platform_mask = 0x02, .driver_data = 0x42 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x16, .steppings = 0x0002, .platform_mask = 0x80, .driver_data = 0x44 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0040, .platform_mask = 0x01, .driver_data = 0x60f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0040, .platform_mask = 0x04, .driver_data = 0x60f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0040, .platform_mask = 0x10, .driver_data = 0x60f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0040, .platform_mask = 0x40, .driver_data = 0x60f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0040, .platform_mask = 0x80, .driver_data = 0x60f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0080, .platform_mask = 0x10, .driver_data = 0x70a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0400, .platform_mask = 0x11, .driver_data = 0xa0b },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0400, .platform_mask = 0x44, .driver_data = 0xa0b },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x17, .steppings = 0x0400, .platform_mask = 0xa0, .driver_data = 0xa0b },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1a, .steppings = 0x0010, .platform_mask = 0x03, .driver_data = 0x12 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1a, .steppings = 0x0020, .platform_mask = 0x03, .driver_data = 0x1d },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1c, .steppings = 0x0004, .platform_mask = 0x01, .driver_data = 0x217 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1c, .steppings = 0x0004, .platform_mask = 0x04, .driver_data = 0x218 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1c, .steppings = 0x0004, .platform_mask = 0x08, .driver_data = 0x219 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1c, .steppings = 0x0400, .platform_mask = 0x01, .driver_data = 0x107 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1c, .steppings = 0x0400, .platform_mask = 0x04, .driver_data = 0x107 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1c, .steppings = 0x0400, .platform_mask = 0x08, .driver_data = 0x107 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1c, .steppings = 0x0400, .platform_mask = 0x10, .driver_data = 0x107 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1d, .steppings = 0x0002, .platform_mask = 0x08, .driver_data = 0x29 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x1e, .steppings = 0x0020, .platform_mask = 0x13, .driver_data = 0xa },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x25, .steppings = 0x0004, .platform_mask = 0x12, .driver_data = 0x11 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x25, .steppings = 0x0020, .platform_mask = 0x92, .driver_data = 0x7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x26, .steppings = 0x0002, .platform_mask = 0x01, .driver_data = 0x104 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x26, .steppings = 0x0002, .platform_mask = 0x02, .driver_data = 0x105 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2a, .steppings = 0x0080, .platform_mask = 0x12, .driver_data = 0x2f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2c, .steppings = 0x0004, .platform_mask = 0x03, .driver_data = 0x1f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2d, .steppings = 0x0040, .platform_mask = 0x6d, .driver_data = 0x621 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2d, .steppings = 0x0080, .platform_mask = 0x6d, .driver_data = 0x71a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2e, .steppings = 0x0040, .platform_mask = 0x04, .driver_data = 0xd },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x2f, .steppings = 0x0004, .platform_mask = 0x05, .driver_data = 0x3b },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x37, .steppings = 0x0100, .platform_mask = 0x02, .driver_data = 0x838 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x37, .steppings = 0x0100, .platform_mask = 0x0c, .driver_data = 0x838 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x37, .steppings = 0x0200, .platform_mask = 0x0f, .driver_data = 0x90d },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3a, .steppings = 0x0200, .platform_mask = 0x12, .driver_data = 0x21 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3c, .steppings = 0x0008, .platform_mask = 0x32, .driver_data = 0x28 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3d, .steppings = 0x0010, .platform_mask = 0xc0, .driver_data = 0x2f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3e, .steppings = 0x0010, .platform_mask = 0xed, .driver_data = 0x42e },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3e, .steppings = 0x0040, .platform_mask = 0xed, .driver_data = 0x600 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3e, .steppings = 0x0080, .platform_mask = 0xed, .driver_data = 0x715 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3f, .steppings = 0x0004, .platform_mask = 0x6f, .driver_data = 0x49 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x3f, .steppings = 0x0010, .platform_mask = 0x80, .driver_data = 0x1a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x45, .steppings = 0x0002, .platform_mask = 0x72, .driver_data = 0x26 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x46, .steppings = 0x0002, .platform_mask = 0x32, .driver_data = 0x1c },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x47, .steppings = 0x0002, .platform_mask = 0x22, .driver_data = 0x22 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x4c, .steppings = 0x0008, .platform_mask = 0x01, .driver_data = 0x368 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x4c, .steppings = 0x0010, .platform_mask = 0x01, .driver_data = 0x411 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x4d, .steppings = 0x0100, .platform_mask = 0x01, .driver_data = 0x12d },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x4e, .steppings = 0x0008, .platform_mask = 0xc0, .driver_data = 0xf0 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0008, .platform_mask = 0x97, .driver_data = 0x1000191 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0010, .platform_mask = 0xb7, .driver_data = 0x2007006 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0020, .platform_mask = 0xb7, .driver_data = 0x3000010 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0080, .platform_mask = 0xbf, .driver_data = 0x5003901 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0800, .platform_mask = 0xbf, .driver_data = 0x7002b01 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x56, .steppings = 0x0004, .platform_mask = 0x10, .driver_data = 0x1c },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x56, .steppings = 0x0008, .platform_mask = 0x10, .driver_data = 0x700001c },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x56, .steppings = 0x0010, .platform_mask = 0x10, .driver_data = 0xf00001a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x56, .steppings = 0x0020, .platform_mask = 0x10, .driver_data = 0xe000015 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x5c, .steppings = 0x0004, .platform_mask = 0x01, .driver_data = 0x14 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x5c, .steppings = 0x0200, .platform_mask = 0x03, .driver_data = 0x48 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x5c, .steppings = 0x0400, .platform_mask = 0x03, .driver_data = 0x28 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x5e, .steppings = 0x0008, .platform_mask = 0x36, .driver_data = 0xf0 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x5f, .steppings = 0x0002, .platform_mask = 0x01, .driver_data = 0x3e },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x66, .steppings = 0x0008, .platform_mask = 0x80, .driver_data = 0x2a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x6a, .steppings = 0x0020, .platform_mask = 0x87, .driver_data = 0xc0002f0 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x6a, .steppings = 0x0040, .platform_mask = 0x87, .driver_data = 0xd000404 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x6c, .steppings = 0x0002, .platform_mask = 0x10, .driver_data = 0x10002d0 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7a, .steppings = 0x0002, .platform_mask = 0x01, .driver_data = 0x42 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7a, .steppings = 0x0100, .platform_mask = 0x01, .driver_data = 0x26 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7e, .steppings = 0x0020, .platform_mask = 0x80, .driver_data = 0xca },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8a, .steppings = 0x0002, .platform_mask = 0x10, .driver_data = 0x33 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8c, .steppings = 0x0002, .platform_mask = 0x80, .driver_data = 0xbc },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8c, .steppings = 0x0004, .platform_mask = 0xc2, .driver_data = 0x3c },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8d, .steppings = 0x0002, .platform_mask = 0xc2, .driver_data = 0x56 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8e, .steppings = 0x0200, .platform_mask = 0x10, .driver_data = 0xf6 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8e, .steppings = 0x0200, .platform_mask = 0xc0, .driver_data = 0xf6 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8e, .steppings = 0x0400, .platform_mask = 0xc0, .driver_data = 0xf6 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8e, .steppings = 0x0800, .platform_mask = 0xd0, .driver_data = 0xf6 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8e, .steppings = 0x1000, .platform_mask = 0x94, .driver_data = 0x100 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0010, .platform_mask = 0x10, .driver_data = 0x2c0003f7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0010, .platform_mask = 0x87, .driver_data = 0x2b000639 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0020, .platform_mask = 0x10, .driver_data = 0x2c0003f7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0020, .platform_mask = 0x87, .driver_data = 0x2b000639 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0040, .platform_mask = 0x10, .driver_data = 0x2c0003f7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0040, .platform_mask = 0x87, .driver_data = 0x2b000639 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0080, .platform_mask = 0x87, .driver_data = 0x2b000639 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0100, .platform_mask = 0x10, .driver_data = 0x2c0003f7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0100, .platform_mask = 0x87, .driver_data = 0x2b000639 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x96, .steppings = 0x0002, .platform_mask = 0x01, .driver_data = 0x1a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x97, .steppings = 0x0004, .platform_mask = 0x07, .driver_data = 0x3a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x97, .steppings = 0x0020, .platform_mask = 0x07, .driver_data = 0x3a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9a, .steppings = 0x0008, .platform_mask = 0x80, .driver_data = 0x437 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9a, .steppings = 0x0010, .platform_mask = 0x40, .driver_data = 0xa },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9a, .steppings = 0x0010, .platform_mask = 0x80, .driver_data = 0x437 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9c, .steppings = 0x0001, .platform_mask = 0x01, .driver_data = 0x24000026 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9e, .steppings = 0x0200, .platform_mask = 0x2a, .driver_data = 0xf8 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9e, .steppings = 0x0400, .platform_mask = 0x22, .driver_data = 0xfa },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9e, .steppings = 0x0800, .platform_mask = 0x02, .driver_data = 0xf6 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9e, .steppings = 0x1000, .platform_mask = 0x22, .driver_data = 0xf8 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9e, .steppings = 0x2000, .platform_mask = 0x22, .driver_data = 0x104 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa5, .steppings = 0x0004, .platform_mask = 0x20, .driver_data = 0x100 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa5, .steppings = 0x0008, .platform_mask = 0x22, .driver_data = 0x100 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa5, .steppings = 0x0020, .platform_mask = 0x22, .driver_data = 0x100 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa6, .steppings = 0x0001, .platform_mask = 0x80, .driver_data = 0x102 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa6, .steppings = 0x0002, .platform_mask = 0x80, .driver_data = 0x100 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa7, .steppings = 0x0002, .platform_mask = 0x02, .driver_data = 0x64 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xaa, .steppings = 0x0010, .platform_mask = 0xe6, .driver_data = 0x24 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xad, .steppings = 0x0002, .platform_mask = 0x20, .driver_data = 0xa0000d1 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xad, .steppings = 0x0002, .platform_mask = 0x95, .driver_data = 0x10003a2 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xaf, .steppings = 0x0008, .platform_mask = 0x01, .driver_data = 0x3000341 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xb5, .steppings = 0x0001, .platform_mask = 0x80, .driver_data = 0xa },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xb7, .steppings = 0x0002, .platform_mask = 0x32, .driver_data = 0x12f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xb7, .steppings = 0x0010, .platform_mask = 0x32, .driver_data = 0x12f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xba, .steppings = 0x0004, .platform_mask = 0xe0, .driver_data = 0x4128 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xba, .steppings = 0x0008, .platform_mask = 0xe0, .driver_data = 0x4128 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xba, .steppings = 0x0100, .platform_mask = 0xe0, .driver_data = 0x4128 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbd, .steppings = 0x0002, .platform_mask = 0x80, .driver_data = 0x11f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbe, .steppings = 0x0001, .platform_mask = 0x19, .driver_data = 0x1d },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbf, .steppings = 0x0004, .platform_mask = 0x07, .driver_data = 0x3a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbf, .steppings = 0x0020, .platform_mask = 0x07, .driver_data = 0x3a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbf, .steppings = 0x0040, .platform_mask = 0x07, .driver_data = 0x3a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbf, .steppings = 0x0080, .platform_mask = 0x07, .driver_data = 0x3a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xc5, .steppings = 0x0004, .platform_mask = 0x82, .driver_data = 0x118 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xc6, .steppings = 0x0004, .platform_mask = 0x82, .driver_data = 0x118 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xc6, .steppings = 0x0010, .platform_mask = 0x82, .driver_data = 0x118 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xca, .steppings = 0x0004, .platform_mask = 0x82, .driver_data = 0x118 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xcf, .steppings = 0x0002, .platform_mask = 0x87, .driver_data = 0x210002a9 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xcf, .steppings = 0x0004, .platform_mask = 0x87, .driver_data = 0x210002a9 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x00, .steppings = 0x0080, .platform_mask = 0x01, .driver_data = 0x12 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x00, .steppings = 0x0080, .platform_mask = 0x02, .driver_data = 0x8 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x00, .steppings = 0x0400, .platform_mask = 0x01, .driver_data = 0x13 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x00, .steppings = 0x0400, .platform_mask = 0x02, .driver_data = 0x15 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x00, .steppings = 0x0400, .platform_mask = 0x04, .driver_data = 0x14 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x01, .steppings = 0x0004, .platform_mask = 0x04, .driver_data = 0x2e },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0010, .platform_mask = 0x02, .driver_data = 0x1f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0010, .platform_mask = 0x04, .driver_data = 0x1e },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0010, .platform_mask = 0x10, .driver_data = 0x21 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0020, .platform_mask = 0x01, .driver_data = 0x29 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0020, .platform_mask = 0x02, .driver_data = 0x2a },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0020, .platform_mask = 0x04, .driver_data = 0x2b },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0020, .platform_mask = 0x10, .driver_data = 0x2c },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0040, .platform_mask = 0x02, .driver_data = 0x10 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0080, .platform_mask = 0x02, .driver_data = 0x38 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0080, .platform_mask = 0x04, .driver_data = 0x37 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0080, .platform_mask = 0x08, .driver_data = 0x39 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0200, .platform_mask = 0x02, .driver_data = 0x2d },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0200, .platform_mask = 0x04, .driver_data = 0x2e },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x02, .steppings = 0x0200, .platform_mask = 0x08, .driver_data = 0x2f },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x03, .steppings = 0x0004, .platform_mask = 0x0d, .driver_data = 0xa },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x03, .steppings = 0x0008, .platform_mask = 0x0d, .driver_data = 0xc },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x03, .steppings = 0x0010, .platform_mask = 0x1d, .driver_data = 0x17 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0002, .platform_mask = 0x02, .driver_data = 0x16 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0002, .platform_mask = 0xbd, .driver_data = 0x17 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0008, .platform_mask = 0x9d, .driver_data = 0x5 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0010, .platform_mask = 0x9d, .driver_data = 0x6 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0080, .platform_mask = 0x9d, .driver_data = 0x3 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0100, .platform_mask = 0x01, .driver_data = 0xc },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0100, .platform_mask = 0x02, .driver_data = 0xe },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0100, .platform_mask = 0x5f, .driver_data = 0x7 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0200, .platform_mask = 0xbd, .driver_data = 0x3 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0400, .platform_mask = 0x5c, .driver_data = 0x4 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x04, .steppings = 0x0400, .platform_mask = 0x5d, .driver_data = 0x2 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x06, .steppings = 0x0004, .platform_mask = 0x04, .driver_data = 0xf },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x06, .steppings = 0x0010, .platform_mask = 0x01, .driver_data = 0x2 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x06, .steppings = 0x0010, .platform_mask = 0x34, .driver_data = 0x4 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x06, .steppings = 0x0020, .platform_mask = 0x01, .driver_data = 0x8 },
+{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0xf, .model = 0x06, .steppings = 0x0100, .platform_mask = 0x22, .driver_data = 0x9 },
_
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure
2026-02-06 23:14 ` [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen
@ 2026-02-08 21:37 ` Borislav Petkov
2026-02-11 18:40 ` Dave Hansen
2026-02-10 23:23 ` Sohil Mehta
1 sibling, 1 reply; 37+ messages in thread
From: Borislav Petkov @ 2026-02-08 21:37 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, sohil.mehta, zhao1.liu, H. Peter Anvin,
Ingo Molnar, Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On Fri, Feb 06, 2026 at 03:14:45PM -0800, Dave Hansen wrote:
> 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-02-06 15:14:23.528790212 -0800
> +++ b/arch/x86/include/asm/processor.h 2026-02-06 15:14:23.567791582 -0800
> @@ -140,6 +140,8 @@ struct cpuinfo_x86 {
> __u32 x86_vfm;
> };
> __u8 x86_stepping;
> + /* Intel-only. 3 bits: */
> + __u8 x86_platform_id;
Can we call this something more generic so that we can do:
/* On Intel: platform ID
/* On AMD: something else
so that we can use this on both vendors?
I don't have any usage in mind on AMD now but it might come in handy some day.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks
2026-02-06 23:14 [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen
` (5 preceding siblings ...)
2026-02-06 23:14 ` [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list Dave Hansen
@ 2026-02-09 10:20 ` Maciej Wieczor-Retman
2026-02-09 15:15 ` Dave Hansen
6 siblings, 1 reply; 37+ messages in thread
From: Maciej Wieczor-Retman @ 2026-02-09 10:20 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, sohil.mehta, zhao1.liu, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
Retested by fabricating the faulting scenario. After adding the patches the old
microcode warning didn't appear and the microcode entry was correctly matched.
Tested-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
(resending due to lost in-reply-to)
On 2026-02-06 at 15:14:38 -0800, Dave Hansen wrote:
>Changes from v1:
> * Fix non-x86 PECI compile issues by lifting some x86 macros
> into an arch-independent header.
> * Make intel_get_platform_id() match its name and return an ID,
> not a mask.
> * Sort #includes
> * Move ->x86_platform_id comment
>
>The platform ID vs. platform mask confusion meant that v1
>worked by total accident. If you tested v1, I'd really
>appreciate you retest this as well.
>
>--
>
>There was a report[1] that CPUs running updated microcode were being
>reported as running old microcode. The reason is that the old
>microcode list neglects to take the platform ID into account.
>
>The platform ID is an Intel-only construct that allows CPUs that
>otherwise have the same model/family/stepping to take different
>microcode revisions. The microcode loader itself already checks this.
>Only the recent "old_microcode" checker failed here.
>
>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 fixes the report of an inaccurate, false positive in the
>'old_microcode' vulnerability file.
>
>1. https://lore.kernel.org/all/38660F8F-499E-48CD-B58B-4822228A5941@nutanix.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>
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks
2026-02-09 10:20 ` [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Maciej Wieczor-Retman
@ 2026-02-09 15:15 ` Dave Hansen
0 siblings, 0 replies; 37+ messages in thread
From: Dave Hansen @ 2026-02-09 15:15 UTC (permalink / raw)
To: Maciej Wieczor-Retman, Dave Hansen
Cc: linux-kernel, sohil.mehta, zhao1.liu, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On 2/9/26 02:20, Maciej Wieczor-Retman wrote:
> Retested by fabricating the faulting scenario. After adding the patches the old
> microcode warning didn't appear and the microcode entry was correctly matched.
>
> Tested-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>
> (resending due to lost in-reply-to)
Thank you for the tag and for retesting!
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-06 23:14 ` [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header Dave Hansen
@ 2026-02-10 22:13 ` Sohil Mehta
2026-02-10 22:17 ` Dave Hansen
0 siblings, 1 reply; 37+ messages in thread
From: Sohil Mehta @ 2026-02-10 22:13 UTC (permalink / raw)
To: Dave Hansen
Cc: zhao1.liu, Borislav Petkov, H. Peter Anvin, Ingo Molnar,
Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86, Iwona Winiarska, LKML
On 2/6/2026 3:14 PM, Dave Hansen wrote:
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> The intel-family.h header uses Vendor/Family/Model macros but it does not
> #include the header where they are defined. If that header is included,
> the build blows up in #include hell.
>
Is the cause of the #include hell the single line in peci-cpu.h?
#include "../../arch/x86/include/asm/intel-family.h"
intel-family.h also uses the X86_VENDOR_INTEL from asm/processor.h
without including that header.
At some point would we want to fix that as well? However, that would
contradict the comment you add in patch 2, "Do not use any x86-specific
headers.." in intel-family.h. Any solution for this would also run into
the same issues.
Therefore, the PECI driver currently does:
/* Copied from x86 <asm/processor.h> */
#define X86_VENDOR_INTEL 0
/* End of copied code */
So, anytime intel-family.h needs to use something x86 specific, the PECI
driver needs to either copy it or we would need to move it to generic code.
> Luckily, these macros are completely independent and do not themselves
> have any dependencies on other code.
>
> Break the VFM_*() macros out into their own header.
>
> Note that the new header is in asm-generic. Believe it or not, the
> intel-family.h header is included from a driver in arch-generic code:
>
> #include "../../arch/x86/include/asm/intel-family.h"
>
> Putting the header in generic code will move in the right direction
> of reducing the amount of code that the "peci" driver needs to copy.
>
AFAIU, the PECI driver is the only user of this VFM stuff in non-x86
code. Are we expecting other generic usages for it?
The VFM macros and the VFM model defines usually go hand-in-hand. Is
there a reason for keeping intel-family header in arch/x86 but the VFM
one in asm-generic/?
I wonder if it would more consistent to move the VFM macros into
arch/x86/include/asm/vfm.h?
And then let the PECI driver do:
#include "../../arch/x86/include/asm/vfm.h"
Though, intel-family.h would probably need:
#ifdef CONFIG_X86
#include <asm/vfm.h>
#endif
This isn't ideal but at least the ugliness is limited to a few lines in
one specific driver. This avoids the need to add x86-specific includes
to the otherwise tidy asm-generic folder.
However, this wouldn't solve the X86_VENDOR_INTEL issue or any future
dependencies in intel-family.h.
Maybe it is time to revisit the reasoning that led to the current PECI
driver implementation :)
https://lore.kernel.org/lkml/67f2cfda-c78b-6282-f5a3-2f345f8e2849@intel.com/
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-10 22:13 ` Sohil Mehta
@ 2026-02-10 22:17 ` Dave Hansen
2026-02-10 23:03 ` Sohil Mehta
0 siblings, 1 reply; 37+ messages in thread
From: Dave Hansen @ 2026-02-10 22:17 UTC (permalink / raw)
To: Sohil Mehta, Dave Hansen
Cc: zhao1.liu, Borislav Petkov, H. Peter Anvin, Ingo Molnar,
Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86, Iwona Winiarska, LKML
On 2/10/26 14:13, Sohil Mehta wrote:
> On 2/6/2026 3:14 PM, Dave Hansen wrote:
>> The intel-family.h header uses Vendor/Family/Model macros but it does not
>> #include the header where they are defined. If that header is included,
>> the build blows up in #include hell.
>>
>
> Is the cause of the #include hell the single line in peci-cpu.h?
>
> #include "../../arch/x86/include/asm/intel-family.h"
Maybe. I didn't investigate too deeply because the fix here at least
moved the needle in the right direction.
...
> AFAIU, the PECI driver is the only user of this VFM stuff in non-x86
> code. Are we expecting other generic usages for it?
Definitely not. PECI is weird.
> The VFM macros and the VFM model defines usually go hand-in-hand. Is
> there a reason for keeping intel-family header in arch/x86 but the VFM
> one in asm-generic/?
We should just move the Intel header as long as it's used in generic code.
> I wonder if it would more consistent to move the VFM macros into
> arch/x86/include/asm/vfm.h?
>
> And then let the PECI driver do:
>
> #include "../../arch/x86/include/asm/vfm.h"
>
> Though, intel-family.h would probably need:
>
> #ifdef CONFIG_X86
> #include <asm/vfm.h>
> #endif
The reality is that we have non-x86 code using an x86 header. That's
crazy and it's very very unusual and we're probably going to keep
accidentally breaking it.
Our only hope is to just move all that gunk to generic code for _real_.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-10 22:17 ` Dave Hansen
@ 2026-02-10 23:03 ` Sohil Mehta
2026-02-10 23:32 ` Luck, Tony
0 siblings, 1 reply; 37+ messages in thread
From: Sohil Mehta @ 2026-02-10 23:03 UTC (permalink / raw)
To: Dave Hansen, Dave Hansen
Cc: zhao1.liu, Borislav Petkov, H. Peter Anvin, Ingo Molnar,
Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86, Iwona Winiarska, LKML
On 2/10/2026 2:17 PM, Dave Hansen wrote:
> The reality is that we have non-x86 code using an x86 header. That's
> crazy and it's very very unusual and we're probably going to keep
> accidentally breaking it.
>
> Our only hope is to just move all that gunk to generic code for _real_.
I agree all VFM stuff needs to be moved to resolve this cleanly.
However, I feel, the partial fix makes the situation worse in the short
term. The new header x86-vfm.h isn't directly used by any generic code.
It is only included from arch/x86 headers.
arch/x86/include/asm/cpu_device_id.h:
5: #include <asm-generic/x86-vfm.h>
arch/x86/include/asm/intel-family.h:
10: #include <asm-generic/x86-vfm.h>
With the new changes, the PECI driver still relies on some copied code
and includes an explicit x86 header (which then includes an x86-vfm
header from asm-generic). intel-family.h *still* implicitly relies on
asm/processor.h.
Instead, would it be better to avoid the first two patches in the series
(until we have a cleaner solution) and do this?
diff --git a/arch/x86/include/asm/microcode.h
b/arch/x86/include/asm/microcode.h
index 3e1987642ecc..92fa64904ee5 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -3,6 +3,7 @@
#define _ASM_X86_MICROCODE_H
#include <asm/cpu.h>
+#include <asm/cpu_device_id.h>
#include <asm/intel-family.h>
#include <asm/msr.h>
I verified that this compiles cleanly. Though it's your call in the end.
I wouldn't push for it further.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper
2026-02-06 23:14 ` [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper Dave Hansen
@ 2026-02-10 23:20 ` Sohil Mehta
2026-02-10 23:23 ` Dave Hansen
0 siblings, 1 reply; 37+ messages in thread
From: Sohil Mehta @ 2026-02-10 23:20 UTC (permalink / raw)
To: Dave Hansen, linux-kernel
Cc: zhao1.liu, Borislav Petkov, H. Peter Anvin, Ingo Molnar,
Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On 2/6/2026 3:14 PM, Dave Hansen wrote:
> b/arch/x86/include/asm/microcode.h | 32 ++++++++++++++++++++++++++++++++
> b/arch/x86/kernel/cpu/microcode/intel.c | 10 +---------
> 2 files changed, 33 insertions(+), 9 deletions(-)
>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
A minor nit:
> - 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 = 1 << intel_get_platform_id();
How about BIT(intel_get_platform_id())?
> }
> EXPORT_SYMBOL_GPL(intel_collect_cpu_info);
>
> _
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper
2026-02-10 23:20 ` Sohil Mehta
@ 2026-02-10 23:23 ` Dave Hansen
0 siblings, 0 replies; 37+ messages in thread
From: Dave Hansen @ 2026-02-10 23:23 UTC (permalink / raw)
To: Sohil Mehta, Dave Hansen, linux-kernel
Cc: zhao1.liu, Borislav Petkov, H. Peter Anvin, Ingo Molnar,
Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On 2/10/26 15:20, Sohil Mehta wrote:
> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Thanks!
> A minor nit:
>
>> - 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 = 1 << intel_get_platform_id();
> How about BIT(intel_get_platform_id())?
... and ack on that. I may fix it at application.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure
2026-02-06 23:14 ` [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen
2026-02-08 21:37 ` Borislav Petkov
@ 2026-02-10 23:23 ` Sohil Mehta
1 sibling, 0 replies; 37+ messages in thread
From: Sohil Mehta @ 2026-02-10 23:23 UTC (permalink / raw)
To: Dave Hansen, linux-kernel
Cc: zhao1.liu, Borislav Petkov, H. Peter Anvin, Ingo Molnar,
Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On 2/6/2026 3:14 PM, 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>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure
2026-02-06 23:14 ` [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure Dave Hansen
@ 2026-02-10 23:27 ` Sohil Mehta
0 siblings, 0 replies; 37+ messages in thread
From: Sohil Mehta @ 2026-02-10 23:27 UTC (permalink / raw)
To: Dave Hansen, linux-kernel
Cc: zhao1.liu, Borislav Petkov, H. Peter Anvin, Ingo Molnar,
Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On 2/6/2026 3:14 PM, Dave Hansen wrote:
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> The existing x86_match_cpu() infrastructure can be used to match
> a bunch of attributes of a CPU: vendor, family, model, steppings
> and CPU features.
>
> But, there's one more attribute that's missing and unable to be
> matched against: the platform ID, enumerated on Intel CPUs in
> MSR_IA32_PLATFORM_ID. It is a little more obscure and is only
> queried during microcode loading. This is because Intel sometimes
> has CPUs with identical family/model/stepping but which need
> different microcode. These CPUs are differentiated with the
> platform ID.
>
> Add a field in 'struct x86_cpu_id' for the platform ID. Similar
> to the stepping field, make the new field a mask of platform IDs.
> Some examples:
>
> 0x01: matches only platform ID 0x0
> 0x02: matches only platform ID 0x1
> 0x03: matches platform IDs 0x0 or 0x1
> 0x80: matches only platform ID 0x7
> 0xff: matches all 8 possible platform IDs
>
> Since the mask is only a byte wide, it nestles in next to another
> u8 and does not even increase the size of 'struct x86_cpu_id'.
>
> Reserve the all 0's value as the wildcard (X86_PLATFORM_ANY). This
> avoids forcing changes changes to existing 'struct x86_cpu_id' users.
"changes" used twice.
> They can just continue to fill the field with 0's and their matching
> will work exactly as before.
>
> Note: If someone is ever looking for space in 'struct x86_cpu_id',
> this new field could probably get stuck over in ->driver_data
> for the one user that there is.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-10 23:03 ` Sohil Mehta
@ 2026-02-10 23:32 ` Luck, Tony
2026-02-10 23:35 ` Dave Hansen
0 siblings, 1 reply; 37+ messages in thread
From: Luck, Tony @ 2026-02-10 23:32 UTC (permalink / raw)
To: Sohil Mehta
Cc: Dave Hansen, Dave Hansen, zhao1.liu, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, x86, Iwona Winiarska, LKML
On Tue, Feb 10, 2026 at 03:03:18PM -0800, Sohil Mehta wrote:
> On 2/10/2026 2:17 PM, Dave Hansen wrote:
>
> > The reality is that we have non-x86 code using an x86 header. That's
> > crazy and it's very very unusual and we're probably going to keep
> > accidentally breaking it.
Maybe the answer is to change the peci code to not do that crazy
include of an arch/x86 file and simply have its own copies of the
#define model numbers for the eight models it cares about?
If they add a ninth at some point, they have to change their code
anyway to add a "case INTEL_FOO:". So adding the model number to
their own local include file doesn't seem like much extra work.
-Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-10 23:32 ` Luck, Tony
@ 2026-02-10 23:35 ` Dave Hansen
2026-02-10 23:52 ` Luck, Tony
0 siblings, 1 reply; 37+ messages in thread
From: Dave Hansen @ 2026-02-10 23:35 UTC (permalink / raw)
To: Luck, Tony, Sohil Mehta
Cc: Dave Hansen, zhao1.liu, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, x86, Iwona Winiarska, LKML
On 2/10/26 15:32, Luck, Tony wrote:
> On Tue, Feb 10, 2026 at 03:03:18PM -0800, Sohil Mehta wrote:
>> On 2/10/2026 2:17 PM, Dave Hansen wrote:
>>
>>> The reality is that we have non-x86 code using an x86 header. That's
>>> crazy and it's very very unusual and we're probably going to keep
>>> accidentally breaking it.
> Maybe the answer is to change the peci code to not do that crazy
> include of an arch/x86 file and simply have its own copies of the
> #define model numbers for the eight models it cares about?
>
> If they add a ninth at some point, they have to change their code
> anyway to add a "case INTEL_FOO:". So adding the model number to
> their own local include file doesn't seem like much extra work.
That sounds fine as well.
Is the PECI model list growing all the time? Like will it grow for the
next decade?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list
2026-02-06 23:14 ` [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list Dave Hansen
@ 2026-02-10 23:39 ` Sohil Mehta
0 siblings, 0 replies; 37+ messages in thread
From: Sohil Mehta @ 2026-02-10 23:39 UTC (permalink / raw)
To: Dave Hansen, linux-kernel
Cc: zhao1.liu, Borislav Petkov, H. Peter Anvin, Ingo Molnar,
Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On 2/6/2026 3:14 PM, Dave Hansen wrote:
>
> b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h | 398 ++++++++++++---------
> 1 file changed, 238 insertions(+), 160 deletions(-)
>
I verified that the new header matches the "microcode-20250512" release
using the updated script at
https://lore.kernel.org/lkml/20260130194753.672739-1-sohil.mehta@intel.com/.
This doesn't skip any models like the previous version.
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-10 23:35 ` Dave Hansen
@ 2026-02-10 23:52 ` Luck, Tony
2026-02-11 21:12 ` Dave Hansen
0 siblings, 1 reply; 37+ messages in thread
From: Luck, Tony @ 2026-02-10 23:52 UTC (permalink / raw)
To: Hansen, Dave, Mehta, Sohil
Cc: Dave Hansen, Liu, Zhao1, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Kohler, Jon, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, x86, Winiarska, Iwona, LKML
> Is the PECI model list growing all the time? Like will it grow for the
> next decade?
Looks like this started in Feb 2022 with HASWELL ... ICELAKE
July 2023 added SAPPHIRE. October 2025 added EMERALD.
Maybe Iwona can future predictions/details when she sees this e-mail thread.
-Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure
2026-02-08 21:37 ` Borislav Petkov
@ 2026-02-11 18:40 ` Dave Hansen
2026-02-12 15:22 ` Borislav Petkov
0 siblings, 1 reply; 37+ messages in thread
From: Dave Hansen @ 2026-02-11 18:40 UTC (permalink / raw)
To: Borislav Petkov, Dave Hansen
Cc: linux-kernel, sohil.mehta, zhao1.liu, H. Peter Anvin,
Ingo Molnar, Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On 2/8/26 13:37, Borislav Petkov wrote:
> On Fri, Feb 06, 2026 at 03:14:45PM -0800, Dave Hansen wrote:
>> 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-02-06 15:14:23.528790212 -0800
>> +++ b/arch/x86/include/asm/processor.h 2026-02-06 15:14:23.567791582 -0800
>> @@ -140,6 +140,8 @@ struct cpuinfo_x86 {
>> __u32 x86_vfm;
>> };
>> __u8 x86_stepping;
>> + /* Intel-only. 3 bits: */
>> + __u8 x86_platform_id;
> Can we call this something more generic so that we can do:
>
> /* On Intel: platform ID
> /* On AMD: something else
>
> so that we can use this on both vendors?
>
> I don't have any usage in mind on AMD now but it might come in handy some day.
I'm racking my brain but having a hard time coming up with a good name
that would work for unknown future AMD things. ;)
Any suggestions? I'm not married to the name in any way.
I could prefix it with 'intel_' to make it more clear that someone _can_
do a union in the future, like we do with "Hardware defined CPU-type".
Or we could do:
union {
u8 intel_platform_id;
u8 amd_unused;
};
to make it utterly clear that it's free for use on AMD if someone goes
looking for AMD-usable space.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-10 23:52 ` Luck, Tony
@ 2026-02-11 21:12 ` Dave Hansen
2026-02-11 21:54 ` Sohil Mehta
2026-02-11 22:21 ` Luck, Tony
0 siblings, 2 replies; 37+ messages in thread
From: Dave Hansen @ 2026-02-11 21:12 UTC (permalink / raw)
To: Luck, Tony, Mehta, Sohil
Cc: Dave Hansen, Liu, Zhao1, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Kohler, Jon, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, x86, Winiarska, Iwona, LKML
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]
On 2/10/26 15:52, Luck, Tony wrote:
>> Is the PECI model list growing all the time? Like will it grow for the
>> next decade?
> Looks like this started in Feb 2022 with HASWELL ... ICELAKE
>
> July 2023 added SAPPHIRE. October 2025 added EMERALD.
>
> Maybe Iwona can future predictions/details when she sees this e-mail thread.
I went and looked at this a bit more. I think we're going to way too
much trouble to share a few constants. It was a valiant effort on the
part of the PECI folks to avoid duplication, but I think it's run its
course.
The x86 code wants and needs to know the logically separate
model/family/stepping. We have oodles of
if (model == INTEL_FOO)
do_foo_thing();
But we basically never care about the format that's in CPUID.01H:EAX.
The PECI code has none of that. It's *just* matching the "id" of the
device to the "id" of the CPU. It just so happens that the "id" that's
chosen matches CPUID.01H:EAX.
So PECI and x86 both want the same data, but they do very different
things with it.
So let's just duplicate the constants. Completely untested patch attached.
Any reason not to do this?
[-- Attachment #2: peci-sanity.patch --]
[-- Type: text/x-patch, Size: 7189 bytes --]
---
b/drivers/hwmon/peci/cputemp.c | 10 +++++-----
b/drivers/peci/core.c | 4 ++--
b/drivers/peci/cpu.c | 16 ++++++++--------
b/drivers/peci/device.c | 34 +++++++---------------------------
b/drivers/peci/internal.h | 4 ++--
b/include/linux/peci-cpu.h | 34 +++++++++-------------------------
b/include/linux/peci.h | 2 +-
7 files changed, 34 insertions(+), 70 deletions(-)
diff -puN drivers/peci/device.c~peci-sanity drivers/peci/device.c
--- a/drivers/peci/device.c~peci-sanity 2026-02-11 12:45:56.914190235 -0800
+++ b/drivers/peci/device.c 2026-02-11 13:06:11.562229733 -0800
@@ -44,6 +44,12 @@ static int peci_get_revision(struct peci
return 0;
}
+/*
+ * Note 'cpu_id' that comes back from the hardware is in the raw
+ * format of x86 CPUID.01H:EAX leaf and includes the CPU Model, Family
+ * and Stepping. But, for the purposes of this driver, it is an opaque
+ * identifier.
+ */
static int peci_get_cpu_id(struct peci_device *device, u32 *cpu_id)
{
struct peci_request *req;
@@ -64,32 +70,6 @@ out_req_free:
return ret;
}
-static unsigned int peci_x86_cpu_family(unsigned int sig)
-{
- unsigned int x86;
-
- x86 = (sig >> 8) & 0xf;
-
- if (x86 == 0xf)
- x86 += (sig >> 20) & 0xff;
-
- return x86;
-}
-
-static unsigned int peci_x86_cpu_model(unsigned int sig)
-{
- unsigned int fam, model;
-
- fam = peci_x86_cpu_family(sig);
-
- model = (sig >> 4) & 0xf;
-
- if (fam >= 0x6)
- model += ((sig >> 16) & 0xf) << 4;
-
- return model;
-}
-
static int peci_device_info_init(struct peci_device *device)
{
u8 revision;
@@ -100,7 +80,7 @@ static int peci_device_info_init(struct
if (ret)
return ret;
- device->info.x86_vfm = IFM(peci_x86_cpu_family(cpu_id), peci_x86_cpu_model(cpu_id));
+ device->info.device_id = cpu_id >> 4;
ret = peci_get_revision(device, &revision);
if (ret)
diff -puN drivers/peci/internal.h~peci-sanity drivers/peci/internal.h
--- a/drivers/peci/internal.h~peci-sanity 2026-02-11 12:47:24.703476027 -0800
+++ b/drivers/peci/internal.h 2026-02-11 12:48:57.278946288 -0800
@@ -66,11 +66,11 @@ struct peci_request *peci_xfer_ep_mmio64
/**
* struct peci_device_id - PECI device data to match
* @data: pointer to driver private data specific to device
- * @x86_vfm: device vendor-family-model
+ * @device_id: device identifier, includes CPU vendor-family-model
*/
struct peci_device_id {
const void *data;
- u32 x86_vfm;
+ u32 device_id;
};
extern const struct device_type peci_device_type;
diff -puN include/linux/peci.h~peci-sanity include/linux/peci.h
--- a/include/linux/peci.h~peci-sanity 2026-02-11 12:47:36.824930119 -0800
+++ b/include/linux/peci.h 2026-02-11 12:50:50.649202205 -0800
@@ -72,7 +72,7 @@ static inline struct peci_controller *to
struct peci_device {
struct device dev;
struct {
- u32 x86_vfm;
+ u32 device_id;
u8 peci_revision;
u8 socket_id;
} info;
diff -puN drivers/hwmon/peci/cputemp.c~peci-sanity drivers/hwmon/peci/cputemp.c
--- a/drivers/hwmon/peci/cputemp.c~peci-sanity 2026-02-11 12:49:00.694074399 -0800
+++ b/drivers/hwmon/peci/cputemp.c 2026-02-11 12:56:12.154297952 -0800
@@ -340,11 +340,11 @@ static int init_core_mask(struct peci_cp
int ret;
/* Get the RESOLVED_CORES register value */
- switch (peci_dev->info.x86_vfm) {
- case INTEL_ICELAKE_X:
- case INTEL_ICELAKE_D:
- case INTEL_SAPPHIRERAPIDS_X:
- case INTEL_EMERALDRAPIDS_X:
+ switch (peci_dev->info.device_id) {
+ case PECI_INTEL_ICELAKE_X:
+ case PECI_INTEL_ICELAKE_D:
+ case PECI_INTEL_SAPPHIRERAPIDS_X:
+ case PECI_INTEL_EMERALDRAPIDS_X:
ret = peci_ep_pci_local_read(peci_dev, 0, reg->bus, reg->dev,
reg->func, reg->offset + 4, &data);
if (ret)
diff -puN drivers/peci/core.c~peci-sanity drivers/peci/core.c
--- a/drivers/peci/core.c~peci-sanity 2026-02-11 12:49:43.989699060 -0800
+++ b/drivers/peci/core.c 2026-02-11 12:49:56.175156483 -0800
@@ -163,8 +163,8 @@ EXPORT_SYMBOL_NS_GPL(devm_peci_controlle
static const struct peci_device_id *
peci_bus_match_device_id(const struct peci_device_id *id, struct peci_device *device)
{
- while (id->x86_vfm != 0) {
- if (id->x86_vfm == device->info.x86_vfm)
+ while (id->device_id != 0) {
+ if (id->device_id == device->info.device_id)
return id;
id++;
}
diff -puN include/linux/peci-cpu.h~peci-sanity include/linux/peci-cpu.h
--- a/include/linux/peci-cpu.h~peci-sanity 2026-02-11 12:51:19.639291420 -0800
+++ b/include/linux/peci-cpu.h 2026-02-11 13:04:24.068100213 -0800
@@ -6,31 +6,15 @@
#include <linux/types.h>
-/* Copied from x86 <asm/processor.h> */
-#define X86_VENDOR_INTEL 0
-
-/* Copied from x86 <asm/cpu_device_id.h> */
-#define VFM_MODEL_BIT 0
-#define VFM_FAMILY_BIT 8
-#define VFM_VENDOR_BIT 16
-#define VFM_RSVD_BIT 24
-
-#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
-#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
-#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
-
-#define VFM_MODEL(vfm) (((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT)
-#define VFM_FAMILY(vfm) (((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT)
-#define VFM_VENDOR(vfm) (((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT)
-
-#define VFM_MAKE(_vendor, _family, _model) ( \
- ((_model) << VFM_MODEL_BIT) | \
- ((_family) << VFM_FAMILY_BIT) | \
- ((_vendor) << VFM_VENDOR_BIT) \
-)
-/* End of copied code */
-
-#include "../../arch/x86/include/asm/intel-family.h"
+#define PECI_INTEL_HASWELL_X 0x306C0
+#define PECI_INTEL_BROADWELL_X 0x406F0
+#define PECI_INTEL_BROADWELL_D 0x50660
+#define PECI_INTEL_SKYLAKE_X 0x50650
+
+#define PECI_INTEL_ICELAKE_X 0x606A0
+#define PECI_INTEL_ICELAKE_D 0x606C0
+#define PECI_INTEL_SAPPHIRERAPIDS_X 0x806F0
+#define PECI_INTEL_EMERALDRAPIDS_X 0xC06F0
#define PECI_PCS_PKG_ID 0 /* Package Identifier Read */
#define PECI_PKG_ID_CPU_ID 0x0000 /* CPUID Info */
diff -puN drivers/peci/cpu.c~peci-sanity drivers/peci/cpu.c
--- a/drivers/peci/cpu.c~peci-sanity 2026-02-11 12:56:48.724675627 -0800
+++ b/drivers/peci/cpu.c 2026-02-11 12:57:18.663803707 -0800
@@ -294,35 +294,35 @@ peci_cpu_probe(struct peci_device *devic
static const struct peci_device_id peci_cpu_device_ids[] = {
{ /* Haswell Xeon */
- .x86_vfm = INTEL_HASWELL_X,
+ .device_id = PECI_INTEL_HASWELL_X,
.data = "hsx",
},
{ /* Broadwell Xeon */
- .x86_vfm = INTEL_BROADWELL_X,
+ .device_id = PECI_INTEL_BROADWELL_X,
.data = "bdx",
},
{ /* Broadwell Xeon D */
- .x86_vfm = INTEL_BROADWELL_D,
+ .device_id = PECI_INTEL_BROADWELL_D,
.data = "bdxd",
},
{ /* Skylake Xeon */
- .x86_vfm = INTEL_SKYLAKE_X,
+ .device_id = PECI_INTEL_SKYLAKE_X,
.data = "skx",
},
{ /* Icelake Xeon */
- .x86_vfm = INTEL_ICELAKE_X,
+ .device_id = PECI_INTEL_ICELAKE_X,
.data = "icx",
},
{ /* Icelake Xeon D */
- .x86_vfm = INTEL_ICELAKE_D,
+ .device_id = PECI_INTEL_ICELAKE_D,
.data = "icxd",
},
{ /* Sapphire Rapids Xeon */
- .x86_vfm = INTEL_SAPPHIRERAPIDS_X,
+ .device_id = PECI_INTEL_SAPPHIRERAPIDS_X,
.data = "spr",
},
{ /* Emerald Rapids Xeon */
- .x86_vfm = INTEL_EMERALDRAPIDS_X,
+ .device_id = PECI_INTEL_EMERALDRAPIDS_X,
.data = "emr",
},
{ }
_
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-11 21:12 ` Dave Hansen
@ 2026-02-11 21:54 ` Sohil Mehta
2026-02-11 22:32 ` Luck, Tony
2026-02-11 22:21 ` Luck, Tony
1 sibling, 1 reply; 37+ messages in thread
From: Sohil Mehta @ 2026-02-11 21:54 UTC (permalink / raw)
To: Dave Hansen, Luck, Tony
Cc: Dave Hansen, Liu, Zhao1, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Kohler, Jon, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, x86, Winiarska, Iwona, LKML
On 2/11/2026 1:12 PM, Dave Hansen wrote:
>
> So PECI and x86 both want the same data, but they do very different
> things with it.
>
> So let's just duplicate the constants. Completely untested patch attached.
>
This looks okay in principle. I haven't tested it yet. But, there seems
to be an inconsistency here?
> static int peci_device_info_init(struct peci_device *device)
> {
> u8 revision;
> @@ -100,7 +80,7 @@ static int peci_device_info_init(struct
> if (ret)
> return ret;
>
> - device->info.x86_vfm = IFM(peci_x86_cpu_family(cpu_id), peci_x86_cpu_model(cpu_id));
> + device->info.device_id = cpu_id >> 4;
>
I imagine this shifting the stepping. Should this be cpu_id & 0xF?
Because the devices are stored with the stepping info:
> +#define PECI_INTEL_HASWELL_X 0x306C0
> +#define PECI_INTEL_BROADWELL_X 0x406F0
> +#define PECI_INTEL_BROADWELL_D 0x50660
> +#define PECI_INTEL_SKYLAKE_X 0x50650
> +
> +#define PECI_INTEL_ICELAKE_X 0x606A0
> +#define PECI_INTEL_ICELAKE_D 0x606C0
> +#define PECI_INTEL_SAPPHIRERAPIDS_X 0x806F0
> +#define PECI_INTEL_EMERALDRAPIDS_X 0xC06F0
>
Or maybe define the CPUs without the stepping bits?
> ret = peci_get_revision(device, &revision);
> if (ret)
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-11 21:12 ` Dave Hansen
2026-02-11 21:54 ` Sohil Mehta
@ 2026-02-11 22:21 ` Luck, Tony
1 sibling, 0 replies; 37+ messages in thread
From: Luck, Tony @ 2026-02-11 22:21 UTC (permalink / raw)
To: Hansen, Dave, Mehta, Sohil
Cc: Dave Hansen, Liu, Zhao1, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Kohler, Jon, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, x86, Winiarska, Iwona, LKML
> But we basically never care about the format that's in CPUID.01H:EAX.
> The PECI code has none of that. It's *just* matching the "id" of the
> device to the "id" of the CPU. It just so happens that the "id" that's
> chosen matches CPUID.01H:EAX.
> So PECI and x86 both want the same data, but they do very different
> things with it.
> So let's just duplicate the constants. Completely untested patch attached.
> Any reason not to do this?
PECI code doesn't care about the stepping. You drop it when initializing
the device_id:
+ device->info.device_id = cpu_id >> 4;
But then you defined all the PECI model constants with the stepping.
E.g.
+#define PECI_INTEL_HASWELL_X 0x306C0
Perhaps drop the trailing '0' nibble and add a comment about the ID
being stepping independent?
-Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-11 21:54 ` Sohil Mehta
@ 2026-02-11 22:32 ` Luck, Tony
2026-02-11 22:35 ` Sohil Mehta
0 siblings, 1 reply; 37+ messages in thread
From: Luck, Tony @ 2026-02-11 22:32 UTC (permalink / raw)
To: Mehta, Sohil, Hansen, Dave
Cc: Dave Hansen, Liu, Zhao1, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Kohler, Jon, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, x86, Winiarska, Iwona, LKML
>> + device->info.device_id = cpu_id >> 4;
>>
>
> I imagine this shifting the stepping. Should this be cpu_id & 0xF?
Fixing here seems to be better than changing the constants. But needs a "~"
/* Ignore the stepping */
device->info.device_id = cpu_id & ~ 0xF;
-Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-11 22:32 ` Luck, Tony
@ 2026-02-11 22:35 ` Sohil Mehta
2026-02-11 23:02 ` Dave Hansen
0 siblings, 1 reply; 37+ messages in thread
From: Sohil Mehta @ 2026-02-11 22:35 UTC (permalink / raw)
To: Luck, Tony, Hansen, Dave
Cc: Dave Hansen, Liu, Zhao1, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Kohler, Jon, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, x86, Winiarska, Iwona, LKML
On 2/11/2026 2:32 PM, Luck, Tony wrote:
>>> + device->info.device_id = cpu_id >> 4;
>>>
>>
>> I imagine this shifting the stepping. Should this be cpu_id & 0xF?
>
> Fixing here seems to be better than changing the constants. But needs a "~"
>
> /* Ignore the stepping */
> device->info.device_id = cpu_id & ~ 0xF;
>
Ah, yes! Error while fixing an error :)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-02-11 22:35 ` Sohil Mehta
@ 2026-02-11 23:02 ` Dave Hansen
0 siblings, 0 replies; 37+ messages in thread
From: Dave Hansen @ 2026-02-11 23:02 UTC (permalink / raw)
To: Sohil Mehta, Luck, Tony
Cc: Dave Hansen, Liu, Zhao1, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Kohler, Jon, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, x86, Winiarska, Iwona, LKML
On 2/11/26 14:35, Sohil Mehta wrote:
> On 2/11/2026 2:32 PM, Luck, Tony wrote:
>>>> + device->info.device_id = cpu_id >> 4;
>>>>
>>> I imagine this shifting the stepping. Should this be cpu_id & 0xF?
>> Fixing here seems to be better than changing the constants. But needs a "~"
>>
>> /* Ignore the stepping */
>> device->info.device_id = cpu_id & ~ 0xF;
>>
> Ah, yes! Error while fixing an error 🙂
Nice catches guys, and thanks for this! I do think masking it like that
is the right thing to do... unless that field that comes off the device
in peci_device_info_init() is always 0's.
There are apparently no public PECI docs so it's hard to tell what the
rules for that field are.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure
2026-02-11 18:40 ` Dave Hansen
@ 2026-02-12 15:22 ` Borislav Petkov
0 siblings, 0 replies; 37+ messages in thread
From: Borislav Petkov @ 2026-02-12 15:22 UTC (permalink / raw)
To: Dave Hansen
Cc: Dave Hansen, linux-kernel, sohil.mehta, zhao1.liu,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On Wed, Feb 11, 2026 at 10:40:21AM -0800, Dave Hansen wrote:
> I'm racking my brain but having a hard time coming up with a good name
> that would work for unknown future AMD things. ;)
>
> Any suggestions? I'm not married to the name in any way.
> I could prefix it with 'intel_' to make it more clear that someone _can_
> do a union in the future, like we do with "Hardware defined CPU-type".
>
> Or we could do:
>
> union {
> u8 intel_platform_id;
> u8 amd_unused;
> };
>
> to make it utterly clear that it's free for use on AMD if someone goes
> looking for AMD-usable space.
That last one LGTM.
And if we need to change it later, we always can - the thing is there to
remind that we have a u8 ready to use.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-01-20 16:34 ` Dave Hansen
@ 2026-01-20 20:54 ` Andy Shevchenko
0 siblings, 0 replies; 37+ messages in thread
From: Andy Shevchenko @ 2026-01-20 20:54 UTC (permalink / raw)
To: Dave Hansen
Cc: Dave Hansen, linux-kernel, sohil.mehta, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On Tue, Jan 20, 2026 at 08:34:49AM -0800, Dave Hansen wrote:
> On 1/20/26 08:22, Andy Shevchenko wrote:
> > On Tue, Jan 20, 2026 at 07:03:31AM -0800, Dave Hansen wrote:
> >> On 1/20/26 00:24, Andy Shevchenko wrote:
> >>>> +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
> >>>> +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
> >>>> +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
> >>> There are tabs after #define, is it on purpose?
> >>> (yes, I know this is simple move, but if not deliberate, we can tweak
> >>> the tabs/spaces while at it)
> >> Yes, you can, but I chose not to here. Is there any compelling reason to
> >> tweak it?
> > The usual style to use spaces there. Using tabs makes it mixed and
> > inconsistent. So the expectation of a define is
> >
> > #define<single space>$FOO<TAB(s)>$VALUE
>
> Remember, this code is being moved, not newly-composed.
See what I put in the parentheses, this is exactly what I admit from
the beginning.
> It's being moved for a bug fix and not being "cleaned up" or massaged
> for other purposes.
Sure, but it makes no direct visible differences if amended. I don't see
why we would bother with an additional patch to fix white spaces.
> In a bug fix series, I tend toward changing as few things as possible.
> That includes fixing up whitespace. I apply patches all the time that
> move code where that code breaks coding-style.rst in _some_way. I'm more
> than happy to ignore the checkpatch warnings there.
>
> I'm also not going to NAK a bug fix that cleans up whitespace. It's
> really submitter's preference. _Both_ are fine.
>
> It's really 100% up to the maintainer that applies it. In this case, the
> maintainer obviously has a preference, so why belabor the point? ;)
Definitely.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-01-20 16:48 ` Luck, Tony
@ 2026-01-20 20:50 ` Shevchenko, Andriy
0 siblings, 0 replies; 37+ messages in thread
From: Shevchenko, Andriy @ 2026-01-20 20:50 UTC (permalink / raw)
To: Luck, Tony
Cc: Dave Hansen, linux-kernel, Mehta, Sohil, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Kohler, Jon, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, x86
On Tue, Jan 20, 2026 at 04:48:55PM +0000, Luck, Tony wrote:
> > > Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> >
> > Still don't understand why people putting Cc list before the cutter. This noise
> > in the commit message and when retrospectively one reads on the small screen (I
> > do on the phone from time to time) it makes it at bare miniumum inconvenient).
> >
> > > 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>
> > > ---
>
> I put stuff above the "---" because I'm a dinosaur using GIT and often use:
>
> $ git format-patch ....
>
> ...
>
> $ git am 00*
I couldn't imagine why I would need to use this flow for my own changes.
We have rebase, worktree, multiple remotes in one tree, etc. I think
the keyword is 'dinosaur' and now is 21st century :-)
> to rebase, reorder, move bits from one patch to another, or generate a new
> version of the series. When I do so the "git am" drops everything after the "---" cut line.
>
> I poked around, but couldn't find any way to make "git am" keep it :-(
That's the idea, to get them dropped when a maintainer applies the series.
lore.kernel.org will keep the list anyway.
Haven't researched `b4 relay`, maybe that one helps to carry the Cc list on...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 37+ messages in thread
* RE: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-01-20 8:24 ` Andy Shevchenko
2026-01-20 15:03 ` Dave Hansen
@ 2026-01-20 16:48 ` Luck, Tony
2026-01-20 20:50 ` Shevchenko, Andriy
1 sibling, 1 reply; 37+ messages in thread
From: Luck, Tony @ 2026-01-20 16:48 UTC (permalink / raw)
To: Shevchenko, Andriy, Dave Hansen
Cc: linux-kernel, Mehta, Sohil, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Kohler, Jon, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, x86
> > Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>
> Still don't understand why people putting Cc list before the cutter. This noise
> in the commit message and when retrospectively one reads on the small screen (I
> do on the phone from time to time) it makes it at bare miniumum inconvenient).
>
> > 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>
> > ---
I put stuff above the "---" because I'm a dinosaur using GIT and often use:
$ git format-patch ....
...
$ git am 00*
to rebase, reorder, move bits from one patch to another, or generate a new
version of the series. When I do so the "git am" drops everything after the "---" cut line.
I poked around, but couldn't find any way to make "git am" keep it :-(
-Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-01-20 16:22 ` Andy Shevchenko
@ 2026-01-20 16:34 ` Dave Hansen
2026-01-20 20:54 ` Andy Shevchenko
0 siblings, 1 reply; 37+ messages in thread
From: Dave Hansen @ 2026-01-20 16:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dave Hansen, linux-kernel, sohil.mehta, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On 1/20/26 08:22, Andy Shevchenko wrote:
> On Tue, Jan 20, 2026 at 07:03:31AM -0800, Dave Hansen wrote:
>> On 1/20/26 00:24, Andy Shevchenko wrote:
>>>> +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
>>>> +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
>>>> +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
>>> There are tabs after #define, is it on purpose?
>>> (yes, I know this is simple move, but if not deliberate, we can tweak
>>> the tabs/spaces while at it)
>> Yes, you can, but I chose not to here. Is there any compelling reason to
>> tweak it?
> The usual style to use spaces there. Using tabs makes it mixed and
> inconsistent. So the expectation of a define is
>
> #define<single space>$FOO<TAB(s)>$VALUE
Remember, this code is being moved, not newly-composed. It's being moved
for a bug fix and not being "cleaned up" or massaged for other purposes.
In a bug fix series, I tend toward changing as few things as possible.
That includes fixing up whitespace. I apply patches all the time that
move code where that code breaks coding-style.rst in _some_way. I'm more
than happy to ignore the checkpatch warnings there.
I'm also not going to NAK a bug fix that cleans up whitespace. It's
really submitter's preference. _Both_ are fine.
It's really 100% up to the maintainer that applies it. In this case, the
maintainer obviously has a preference, so why belabor the point? ;)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-01-20 15:03 ` Dave Hansen
@ 2026-01-20 16:22 ` Andy Shevchenko
2026-01-20 16:34 ` Dave Hansen
0 siblings, 1 reply; 37+ messages in thread
From: Andy Shevchenko @ 2026-01-20 16:22 UTC (permalink / raw)
To: Dave Hansen
Cc: Dave Hansen, linux-kernel, sohil.mehta, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta,
Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On Tue, Jan 20, 2026 at 07:03:31AM -0800, Dave Hansen wrote:
> On 1/20/26 00:24, Andy Shevchenko wrote:
> >> +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
> >> +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
> >> +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
> > There are tabs after #define, is it on purpose?
> > (yes, I know this is simple move, but if not deliberate, we can tweak
> > the tabs/spaces while at it)
>
> Yes, you can, but I chose not to here. Is there any compelling reason to
> tweak it?
The usual style to use spaces there. Using tabs makes it mixed and
inconsistent. So the expectation of a define is
#define<single space>$FOO<TAB(s)>$VALUE
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-01-20 8:24 ` Andy Shevchenko
@ 2026-01-20 15:03 ` Dave Hansen
2026-01-20 16:22 ` Andy Shevchenko
2026-01-20 16:48 ` Luck, Tony
1 sibling, 1 reply; 37+ messages in thread
From: Dave Hansen @ 2026-01-20 15:03 UTC (permalink / raw)
To: Andy Shevchenko, Dave Hansen
Cc: linux-kernel, sohil.mehta, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On 1/20/26 00:24, Andy Shevchenko wrote:
>> +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
>> +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
>> +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
> There are tabs after #define, is it on purpose?
> (yes, I know this is simple move, but if not deliberate, we can tweak
> the tabs/spaces while at it)
Yes, you can, but I chose not to here. Is there any compelling reason to
tweak it?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-01-19 19:50 ` [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header Dave Hansen
@ 2026-01-20 8:24 ` Andy Shevchenko
2026-01-20 15:03 ` Dave Hansen
2026-01-20 16:48 ` Luck, Tony
0 siblings, 2 replies; 37+ messages in thread
From: Andy Shevchenko @ 2026-01-20 8:24 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, sohil.mehta, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
On Mon, Jan 19, 2026 at 11:50:49AM -0800, Dave Hansen wrote:
> The intel-family.h header uses Vendor/Family/Model macros but it does not
> #include the header where they are defined. If that header is included,
> the build blows up in #include hell.
>
> Luckily, these macros are completely independent and do not themselves
> have any dependencies on other code.
>
> Break the VFM_*() macros out into their own header.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Still don't understand why people putting Cc list before the cutter. This noise
in the commit message and when retrospectively one reads on the small screen (I
do on the phone from time to time) it makes it at bare miniumum inconvenient).
> 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>
> ---
...
> +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
> +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
> +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
There are tabs after #define, is it on purpose?
(yes, I know this is simple move, but if not deliberate, we can tweak
the tabs/spaces while at it)
...
> +#define VFM_MAKE(_vendor, _family, _model) ( \
Ditto.
> + ((_model) << VFM_MODEL_BIT) | \
> + ((_family) << VFM_FAMILY_BIT) | \
> + ((_vendor) << VFM_VENDOR_BIT) \
> +)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header
2026-01-19 19:50 [PATCH 0/6] " Dave Hansen
@ 2026-01-19 19:50 ` Dave Hansen
2026-01-20 8:24 ` Andy Shevchenko
0 siblings, 1 reply; 37+ messages in thread
From: Dave Hansen @ 2026-01-19 19:50 UTC (permalink / raw)
To: linux-kernel
Cc: sohil.mehta, Dave Hansen, Borislav Petkov, H. Peter Anvin,
Ingo Molnar, Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel),
Thomas Gleixner, Tony Luck, x86
From: Dave Hansen <dave.hansen@linux.intel.com>
The intel-family.h header uses Vendor/Family/Model macros but it does not
#include the header where they are defined. If that header is included,
the build blows up in #include hell.
Luckily, these macros are completely independent and do not themselves
have any dependencies on other code.
Break the VFM_*() macros out into their own header.
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/cpu_device_id.h | 33 ----------------------------
b/arch/x86/include/asm/vfm.h | 38 +++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 32 deletions(-)
diff -puN arch/x86/include/asm/cpu_device_id.h~x86-vfm_h arch/x86/include/asm/cpu_device_id.h
--- a/arch/x86/include/asm/cpu_device_id.h~x86-vfm_h 2026-01-19 11:38:07.714851835 -0800
+++ b/arch/x86/include/asm/cpu_device_id.h 2026-01-19 11:38:07.717851949 -0800
@@ -2,38 +2,7 @@
#ifndef _ASM_X86_CPU_DEVICE_ID
#define _ASM_X86_CPU_DEVICE_ID
-/*
- * Can't use <linux/bitfield.h> because it generates expressions that
- * cannot be used in structure initializers. Bitfield construction
- * here must match the union in struct cpuinfo_86:
- * union {
- * struct {
- * __u8 x86_model;
- * __u8 x86;
- * __u8 x86_vendor;
- * __u8 x86_reserved;
- * };
- * __u32 x86_vfm;
- * };
- */
-#define VFM_MODEL_BIT 0
-#define VFM_FAMILY_BIT 8
-#define VFM_VENDOR_BIT 16
-#define VFM_RSVD_BIT 24
-
-#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
-#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
-#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
-
-#define VFM_MODEL(vfm) (((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT)
-#define VFM_FAMILY(vfm) (((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT)
-#define VFM_VENDOR(vfm) (((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT)
-
-#define VFM_MAKE(_vendor, _family, _model) ( \
- ((_model) << VFM_MODEL_BIT) | \
- ((_family) << VFM_FAMILY_BIT) | \
- ((_vendor) << VFM_VENDOR_BIT) \
-)
+#include <asm/vfm.h>
/*
* Declare drivers belonging to specific x86 CPUs
diff -puN /dev/null arch/x86/include/asm/vfm.h
--- /dev/null 2025-12-13 18:24:00.793641044 -0800
+++ b/arch/x86/include/asm/vfm.h 2026-01-19 11:38:07.717851949 -0800
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_VFM
+#define _ASM_X86_VFM
+
+/*
+ * Can't use <linux/bitfield.h> because it generates expressions that
+ * cannot be used in structure initializers. Bitfield construction
+ * here must match the union in struct cpuinfo_86:
+ * union {
+ * struct {
+ * __u8 x86_model;
+ * __u8 x86;
+ * __u8 x86_vendor;
+ * __u8 x86_reserved;
+ * };
+ * __u32 x86_vfm;
+ * };
+ */
+#define VFM_MODEL_BIT 0
+#define VFM_FAMILY_BIT 8
+#define VFM_VENDOR_BIT 16
+#define VFM_RSVD_BIT 24
+
+#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT)
+#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT)
+#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT)
+
+#define VFM_MODEL(vfm) (((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT)
+#define VFM_FAMILY(vfm) (((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT)
+#define VFM_VENDOR(vfm) (((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT)
+
+#define VFM_MAKE(_vendor, _family, _model) ( \
+ ((_model) << VFM_MODEL_BIT) | \
+ ((_family) << VFM_FAMILY_BIT) | \
+ ((_vendor) << VFM_VENDOR_BIT) \
+)
+
+#endif /* _ASM_X86_VFM */
_
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2026-02-12 15:22 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-06 23:14 [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen
2026-02-06 23:14 ` [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header Dave Hansen
2026-02-10 22:13 ` Sohil Mehta
2026-02-10 22:17 ` Dave Hansen
2026-02-10 23:03 ` Sohil Mehta
2026-02-10 23:32 ` Luck, Tony
2026-02-10 23:35 ` Dave Hansen
2026-02-10 23:52 ` Luck, Tony
2026-02-11 21:12 ` Dave Hansen
2026-02-11 21:54 ` Sohil Mehta
2026-02-11 22:32 ` Luck, Tony
2026-02-11 22:35 ` Sohil Mehta
2026-02-11 23:02 ` Dave Hansen
2026-02-11 22:21 ` Luck, Tony
2026-02-06 23:14 ` [PATCH 2/6] x86/cpu: Add missing #include Dave Hansen
2026-02-06 23:14 ` [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper Dave Hansen
2026-02-10 23:20 ` Sohil Mehta
2026-02-10 23:23 ` Dave Hansen
2026-02-06 23:14 ` [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen
2026-02-08 21:37 ` Borislav Petkov
2026-02-11 18:40 ` Dave Hansen
2026-02-12 15:22 ` Borislav Petkov
2026-02-10 23:23 ` Sohil Mehta
2026-02-06 23:14 ` [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure Dave Hansen
2026-02-10 23:27 ` Sohil Mehta
2026-02-06 23:14 ` [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list Dave Hansen
2026-02-10 23:39 ` Sohil Mehta
2026-02-09 10:20 ` [PATCH 0/6] [v2] x86/cpu: Take Intel platform into account for old microcode checks Maciej Wieczor-Retman
2026-02-09 15:15 ` Dave Hansen
-- strict thread matches above, loose matches on Subject: below --
2026-01-19 19:50 [PATCH 0/6] " Dave Hansen
2026-01-19 19:50 ` [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header Dave Hansen
2026-01-20 8:24 ` Andy Shevchenko
2026-01-20 15:03 ` Dave Hansen
2026-01-20 16:22 ` Andy Shevchenko
2026-01-20 16:34 ` Dave Hansen
2026-01-20 20:54 ` Andy Shevchenko
2026-01-20 16:48 ` Luck, Tony
2026-01-20 20:50 ` Shevchenko, Andriy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome