* [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks
@ 2026-01-19 19:50 Dave Hansen
2026-01-19 19:50 ` [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header Dave Hansen
` (7 more replies)
0 siblings, 8 replies; 44+ 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
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] 44+ messages in thread* [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header 2026-01-19 19:50 [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen @ 2026-01-19 19:50 ` Dave Hansen 2026-01-20 8:24 ` Andy Shevchenko 2026-01-19 19:50 ` [PATCH 2/6] x86/cpu: Add missing #include Dave Hansen ` (6 subsequent siblings) 7 siblings, 1 reply; 44+ 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] 44+ 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; 44+ 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] 44+ 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; 44+ 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] 44+ 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; 44+ 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] 44+ 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; 44+ 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] 44+ 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; 44+ 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] 44+ 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; 44+ messages in thread From: Luck, Tony @ 2026-01-20 16:48 UTC (permalink / raw) To: Shevchenko, Andriy, Dave Hansen Cc: linux-kernel@vger.kernel.org, Mehta, Sohil, Borislav Petkov, H. Peter Anvin, Ingo Molnar, Kohler, Jon, Pawan Gupta, Peter Zijlstra (Intel), Thomas Gleixner, x86@kernel.org > > 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] 44+ 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; 44+ messages in thread From: Shevchenko, Andriy @ 2026-01-20 20:50 UTC (permalink / raw) To: Luck, Tony Cc: Dave Hansen, linux-kernel@vger.kernel.org, Mehta, Sohil, Borislav Petkov, H. Peter Anvin, Ingo Molnar, Kohler, Jon, Pawan Gupta, Peter Zijlstra (Intel), Thomas Gleixner, x86@kernel.org 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] 44+ messages in thread
* [PATCH 2/6] x86/cpu: Add missing #include 2026-01-19 19:50 [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen 2026-01-19 19:50 ` [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header Dave Hansen @ 2026-01-19 19:50 ` Dave Hansen 2026-01-20 0:26 ` Dave Hansen 2026-01-19 19:50 ` [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper Dave Hansen ` (5 subsequent siblings) 7 siblings, 1 reply; 44+ 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. It must be depending on implicit includes. Include the required header explicitly. 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 | 2 ++ 1 file changed, 2 insertions(+) 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-01-19 11:38:08.254872476 -0800 +++ b/arch/x86/include/asm/intel-family.h 2026-01-19 11:38:08.257872590 -0800 @@ -2,6 +2,8 @@ #ifndef _ASM_X86_INTEL_FAMILY_H #define _ASM_X86_INTEL_FAMILY_H +#include <asm/vfm.h> + /* * "Big Core" Processors (Branded as Core, Xeon, etc...) * _ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 2/6] x86/cpu: Add missing #include 2026-01-19 19:50 ` [PATCH 2/6] x86/cpu: Add missing #include Dave Hansen @ 2026-01-20 0:26 ` Dave Hansen 2026-01-20 8:19 ` Andy Shevchenko 0 siblings, 1 reply; 44+ messages in thread From: Dave Hansen @ 2026-01-20 0:26 UTC (permalink / raw) To: Dave Hansen, linux-kernel Cc: sohil.mehta, Borislav Petkov, H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel), Thomas Gleixner, Tony Luck, x86 On 1/19/26 11:50, Dave Hansen wrote: > 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-01-19 11:38:08.254872476 -0800 > +++ b/arch/x86/include/asm/intel-family.h 2026-01-19 11:38:08.257872590 -0800 > @@ -2,6 +2,8 @@ > #ifndef _ASM_X86_INTEL_FAMILY_H > #define _ASM_X86_INTEL_FAMILY_H > > +#include <asm/vfm.h> > + > /* > * "Big Core" Processors (Branded as Core, Xeon, etc...) > * In a private 0-day mail, it told me: > On 1/19/26 15:33, kernel test robot wrote: > ...> config: parisc-randconfig-001-20260120...> In file included from include/linux/peci-cpu.h:33, >> from drivers/peci/device.c:6: >>>> include/linux/../../arch/x86/include/asm/intel-family.h:5:10: fatal error: asm/vfm.h: No such file or directory >> #include <asm/vfm.h> >> ^~~~~~~~~~~ >> compilation terminated. >> >> >> vim +5 include/linux/../../arch/x86/include/asm/intel-family.h I made a change to intel-family.h and it broke a parisc config. All thanks to the PECI header that does: #include "../../arch/x86/include/asm/intel-family.h" in arch-independent code. I'll fix this up in a v2 but reviews on v1 are still appreciated. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 2/6] x86/cpu: Add missing #include 2026-01-20 0:26 ` Dave Hansen @ 2026-01-20 8:19 ` Andy Shevchenko 2026-01-20 15:35 ` Dave Hansen 0 siblings, 1 reply; 44+ messages in thread From: Andy Shevchenko @ 2026-01-20 8:19 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 Mon, Jan 19, 2026 at 04:26:33PM -0800, Dave Hansen wrote: > On 1/19/26 11:50, Dave Hansen wrote: > In a private 0-day mail, it told me: There are two reports publicly available. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 2/6] x86/cpu: Add missing #include 2026-01-20 8:19 ` Andy Shevchenko @ 2026-01-20 15:35 ` Dave Hansen 0 siblings, 0 replies; 44+ messages in thread From: Dave Hansen @ 2026-01-20 15:35 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 00:19, Andy Shevchenko wrote: > On Mon, Jan 19, 2026 at 04:26:33PM -0800, Dave Hansen wrote: >> On 1/19/26 11:50, Dave Hansen wrote: >> In a private 0-day mail, it told me: > There are two reports publicly available. By "private", I meant "not cc'd to LKML nor any of the folks on this cc list". There is a lore link for it, though, which I guess I could have used. But I mainly wanted to tell the folks who were reading this via LKML or who were on cc why they didn't see the report. Oh, and one of those reports was sent *after* I sent this message. I'd much rather have you look at the code or changelogs! ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper 2026-01-19 19:50 [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen 2026-01-19 19:50 ` [PATCH 1/6] x86/cpu: Break Vendor/Family/Model macros into separate header Dave Hansen 2026-01-19 19:50 ` [PATCH 2/6] x86/cpu: Add missing #include Dave Hansen @ 2026-01-19 19:50 ` Dave Hansen 2026-01-20 3:07 ` Chao Gao 2026-01-22 19:26 ` Sohil Mehta 2026-01-19 19:50 ` [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen ` (4 subsequent siblings) 7 siblings, 2 replies; 44+ 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 only code that cares about the platform ID is the microcode update code itself. To facilitate storing the platform ID in a more generic place and using it outside of the microcode update itself, put the enumeration into a helper function in a header. Mirror intel_get_microcode_revision()'s naming and location. But, moving away from intel_collect_cpu_info() means that the model and family information in CPUID is not readily available. Just call CPUID again. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: x86@kernel.org Cc: Jon Kohler <jon@nutanix.com> --- b/arch/x86/include/asm/microcode.h | 31 +++++++++++++++++++++++++++++++ b/arch/x86/kernel/cpu/microcode/intel.c | 10 +--------- 2 files changed, 32 insertions(+), 9 deletions(-) diff -puN arch/x86/include/asm/microcode.h~refactor-get-processor-flags arch/x86/include/asm/microcode.h --- a/arch/x86/include/asm/microcode.h~refactor-get-processor-flags 2026-01-19 11:38:08.775892390 -0800 +++ b/arch/x86/include/asm/microcode.h 2026-01-19 11:38:08.783892696 -0800 @@ -2,7 +2,9 @@ #ifndef _ASM_X86_MICROCODE_H #define _ASM_X86_MICROCODE_H +#include <asm/cpu.h> #include <asm/msr.h> +#include <asm/intel-family.h> struct cpu_signature { unsigned int sig; @@ -75,6 +77,35 @@ static inline u32 intel_get_microcode_re return rev; } + +/* + * Use CPUID to generate a "vfm" value. Useful + * before 'cpuinfo_x86' structures are populated. + */ +static inline u32 intel_cpuid_vfm(void) +{ + u32 eax = cpuid_eax(1); + u32 fam = x86_family(eax); + u32 model = x86_model(eax); + + return IFM(fam, model); +} + +static inline u32 intel_get_platform_id(void) +{ + unsigned int val[2]; + + /* + * This can be called early. Use CPUID directly to + * generate the VFM value for this CPU. + */ + if (intel_cpuid_vfm() < INTEL_PENTIUM_III_DESCHUTES) + return 0; + + /* get processor flags from MSR 0x17 */ + native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]); + return 1 << ((val[1] >> 18) & 7); +} #endif /* !CONFIG_CPU_SUP_INTEL */ bool microcode_nmi_handler(void); diff -puN arch/x86/kernel/cpu/microcode/intel.c~refactor-get-processor-flags arch/x86/kernel/cpu/microcode/intel.c --- a/arch/x86/kernel/cpu/microcode/intel.c~refactor-get-processor-flags 2026-01-19 11:38:08.780892582 -0800 +++ b/arch/x86/kernel/cpu/microcode/intel.c 2026-01-19 11:38:08.783892696 -0800 @@ -123,16 +123,8 @@ static inline unsigned int exttable_size void intel_collect_cpu_info(struct cpu_signature *sig) { sig->sig = cpuid_eax(1); - sig->pf = 0; sig->rev = intel_get_microcode_revision(); - - if (IFM(x86_family(sig->sig), x86_model(sig->sig)) >= INTEL_PENTIUM_III_DESCHUTES) { - unsigned int val[2]; - - /* get processor flags from MSR 0x17 */ - native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]); - sig->pf = 1 << ((val[1] >> 18) & 7); - } + sig->pf = intel_get_platform_id(); } EXPORT_SYMBOL_GPL(intel_collect_cpu_info); _ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper 2026-01-19 19:50 ` [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper Dave Hansen @ 2026-01-20 3:07 ` Chao Gao 2026-01-20 16:06 ` Dave Hansen 2026-01-22 19:26 ` Sohil Mehta 1 sibling, 1 reply; 44+ messages in thread From: Chao Gao @ 2026-01-20 3:07 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:53AM -0800, Dave Hansen wrote: > >From: Dave Hansen <dave.hansen@linux.intel.com> > >The only code that cares about the platform ID is the microcode update >code itself. To facilitate storing the platform ID in a more generic >place and using it outside of the microcode update itself, put the >enumeration into a helper function in a header. Mirror >intel_get_microcode_revision()'s naming and location. > >But, moving away from intel_collect_cpu_info() means that the model >and family information in CPUID is not readily available. Just call >CPUID again. > >Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> >Cc: Thomas Gleixner <tglx@kernel.org> >Cc: Ingo Molnar <mingo@redhat.com> >Cc: Borislav Petkov <bp@alien8.de> >Cc: Dave Hansen <dave.hansen@linux.intel.com> >Cc: "H. Peter Anvin" <hpa@zytor.com> >Cc: Tony Luck <tony.luck@intel.com> >Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> >Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> >Cc: x86@kernel.org >Cc: Jon Kohler <jon@nutanix.com> >--- > > b/arch/x86/include/asm/microcode.h | 31 +++++++++++++++++++++++++++++++ > b/arch/x86/kernel/cpu/microcode/intel.c | 10 +--------- > 2 files changed, 32 insertions(+), 9 deletions(-) > >diff -puN arch/x86/include/asm/microcode.h~refactor-get-processor-flags arch/x86/include/asm/microcode.h >--- a/arch/x86/include/asm/microcode.h~refactor-get-processor-flags 2026-01-19 11:38:08.775892390 -0800 >+++ b/arch/x86/include/asm/microcode.h 2026-01-19 11:38:08.783892696 -0800 >@@ -2,7 +2,9 @@ > #ifndef _ASM_X86_MICROCODE_H > #define _ASM_X86_MICROCODE_H > >+#include <asm/cpu.h> > #include <asm/msr.h> >+#include <asm/intel-family.h> nit: You may want to sort the header files alphabetically. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper 2026-01-20 3:07 ` Chao Gao @ 2026-01-20 16:06 ` Dave Hansen 2026-01-20 20:59 ` Andy Shevchenko 0 siblings, 1 reply; 44+ messages in thread From: Dave Hansen @ 2026-01-20 16:06 UTC (permalink / raw) To: Chao Gao, 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/19/26 19:07, Chao Gao wrote: ... >> +#include <asm/cpu.h> >> #include <asm/msr.h> >> +#include <asm/intel-family.h> > nit: You may want to sort the header files alphabetically. I was probably going for christmas tree here or something. But, seriously, I don't think we've written down any guidance on header ordering for tip or in the tree in general. It's still kinda the wild west, I think. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper 2026-01-20 16:06 ` Dave Hansen @ 2026-01-20 20:59 ` Andy Shevchenko 0 siblings, 0 replies; 44+ messages in thread From: Andy Shevchenko @ 2026-01-20 20:59 UTC (permalink / raw) To: Dave Hansen Cc: Chao Gao, 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:06:41AM -0800, Dave Hansen wrote: > On 1/19/26 19:07, Chao Gao wrote: ... > >> +#include <asm/cpu.h> > >> #include <asm/msr.h> > >> +#include <asm/intel-family.h> > > nit: You may want to sort the header files alphabetically. > > I was probably going for christmas tree here or something. But, > seriously, I don't think we've written down any guidance on header > ordering for tip or in the tree in general. > > It's still kinda the wild west, I think. It was unclear why you put these two new headers in such an order. Because it feels like you wanted something like alphabetical, but something went differently. For the xmas tree I would expect them still go together #include <asm/msr.h> #include <asm/cpu.h> #include <asm/intel-family.h> But personally I'm with Chao Gao, the alphabetical is easier to maintain as it's natural order that many people got for many years starting from kindergarten times. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper 2026-01-19 19:50 ` [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper Dave Hansen 2026-01-20 3:07 ` Chao Gao @ 2026-01-22 19:26 ` Sohil Mehta 1 sibling, 0 replies; 44+ messages in thread From: Sohil Mehta @ 2026-01-22 19:26 UTC (permalink / raw) To: Dave Hansen, linux-kernel Cc: Borislav Petkov, H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel), Thomas Gleixner, Tony Luck, x86 On 1/19/2026 11:50 AM, Dave Hansen wrote: > +static inline u32 intel_get_platform_id(void) > +{ > + unsigned int val[2]; > + > + /* > + * This can be called early. Use CPUID directly to > + * generate the VFM value for this CPU. > + */ > + if (intel_cpuid_vfm() < INTEL_PENTIUM_III_DESCHUTES) > + return 0; > + > + /* get processor flags from MSR 0x17 */ > + native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]); > + return 1 << ((val[1] >> 18) & 7); > +} Would it be better to use a *native_rdmsrq* and proper #defines instead of passing the two ints and operating on them using magic values? I understand the desire to keep this bugfix series as minimal as possible. But doing this now makes it easier to understand this helper and what it is returning exactly. That would avoid the confusion in patch 4 between x86_platform_id and platform_mask. If you prefer to leave the helper as-is, at a minimum, should we rename it to intel_get_platform_mask()? Also, the variable name in struct cpuinfo_x86 should then be x86_platform_mask. > #endif /* !CONFIG_CPU_SUP_INTEL */ > > bool microcode_nmi_handler(void); > diff -puN arch/x86/kernel/cpu/microcode/intel.c~refactor-get-processor-flags arch/x86/kernel/cpu/microcode/intel.c > --- a/arch/x86/kernel/cpu/microcode/intel.c~refactor-get-processor-flags 2026-01-19 11:38:08.780892582 -0800 > +++ b/arch/x86/kernel/cpu/microcode/intel.c 2026-01-19 11:38:08.783892696 -0800 > @@ -123,16 +123,8 @@ static inline unsigned int exttable_size > void intel_collect_cpu_info(struct cpu_signature *sig) > { > sig->sig = cpuid_eax(1); > - sig->pf = 0; > sig->rev = intel_get_microcode_revision(); > - > - if (IFM(x86_family(sig->sig), x86_model(sig->sig)) >= INTEL_PENTIUM_III_DESCHUTES) { > - unsigned int val[2]; > - > - /* get processor flags from MSR 0x17 */ > - native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]); > - sig->pf = 1 << ((val[1] >> 18) & 7); > - } > + sig->pf = intel_get_platform_id(); > } > EXPORT_SYMBOL_GPL(intel_collect_cpu_info); > > _ ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-19 19:50 [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen ` (2 preceding siblings ...) 2026-01-19 19:50 ` [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper Dave Hansen @ 2026-01-19 19:50 ` Dave Hansen 2026-01-20 3:14 ` Chao Gao 2026-01-20 8:27 ` Andy Shevchenko 2026-01-19 19:50 ` [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure Dave Hansen ` (3 subsequent siblings) 7 siblings, 2 replies; 44+ 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 end goal here is to be able to do x86_match_cpu() and match on a specific platform ID. While it would be possible to stash this ID off somewhere or read it dynamically, that approaches would not be consistent with the other fields which can be matched. Read the platform ID and store it in cpuinfo_x86->x86_platform_id. There are lots of sites to set this new field. Place it near the place c->microcode is established since the platform ID is so closely intertwined with microcode updates. Note: This should not grow the size of 'struct cpuinfo_x86' in practice since the u8 fits next to another u8 in the structure. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: x86@kernel.org Cc: Jon Kohler <jon@nutanix.com> --- b/arch/x86/include/asm/processor.h | 1 + b/arch/x86/kernel/cpu/common.c | 4 +++- b/arch/x86/kernel/cpu/intel.c | 1 + 3 files changed, 5 insertions(+), 1 deletion(-) diff -puN arch/x86/include/asm/processor.h~cpu-x86_stepping arch/x86/include/asm/processor.h --- a/arch/x86/include/asm/processor.h~cpu-x86_stepping 2026-01-19 11:38:09.341914025 -0800 +++ b/arch/x86/include/asm/processor.h 2026-01-19 11:38:09.444917962 -0800 @@ -140,6 +140,7 @@ struct cpuinfo_x86 { __u32 x86_vfm; }; __u8 x86_stepping; + __u8 x86_platform_id; /* Intel-only. 3 bits */ #ifdef CONFIG_X86_64 /* Number of 4K pages in DTLB/ITLB combined(in pages): */ int x86_tlbsize; diff -puN arch/x86/kernel/cpu/common.c~cpu-x86_stepping arch/x86/kernel/cpu/common.c --- a/arch/x86/kernel/cpu/common.c~cpu-x86_stepping 2026-01-19 11:38:09.428917350 -0800 +++ b/arch/x86/kernel/cpu/common.c 2026-01-19 11:38:09.445918000 -0800 @@ -1981,7 +1981,9 @@ static void identify_cpu(struct cpuinfo_ c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size = 0; c->x86_vendor = X86_VENDOR_UNKNOWN; - c->x86_model = c->x86_stepping = 0; /* So far unknown... */ + c->x86_model = 0; + c->x86_stepping = 0; + c->x86_platform_id = 0; c->x86_vendor_id[0] = '\0'; /* Unset */ c->x86_model_id[0] = '\0'; /* Unset */ #ifdef CONFIG_X86_64 diff -puN arch/x86/kernel/cpu/intel.c~cpu-x86_stepping arch/x86/kernel/cpu/intel.c --- a/arch/x86/kernel/cpu/intel.c~cpu-x86_stepping 2026-01-19 11:38:09.441917848 -0800 +++ b/arch/x86/kernel/cpu/intel.c 2026-01-19 11:38:09.445918000 -0800 @@ -205,6 +205,7 @@ static void early_init_intel(struct cpui if (c->x86 >= 6 && !cpu_has(c, X86_FEATURE_IA64)) c->microcode = intel_get_microcode_revision(); + c->x86_platform_id = intel_get_platform_id(); /* Now if any of them are set, check the blacklist and clear the lot */ if ((cpu_has(c, X86_FEATURE_SPEC_CTRL) || _ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-19 19:50 ` [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen @ 2026-01-20 3:14 ` Chao Gao 2026-01-20 15:22 ` Dave Hansen 2026-01-20 8:27 ` Andy Shevchenko 1 sibling, 1 reply; 44+ messages in thread From: Chao Gao @ 2026-01-20 3:14 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:55AM -0800, Dave Hansen wrote: > >From: Dave Hansen <dave.hansen@linux.intel.com> > >The end goal here is to be able to do x86_match_cpu() and match on a >specific platform ID. While it would be possible to stash this ID >off somewhere or read it dynamically, that approaches would not be >consistent with the other fields which can be matched. > >Read the platform ID and store it in cpuinfo_x86->x86_platform_id. > >There are lots of sites to set this new field. Place it near >the place c->microcode is established since the platform ID is >so closely intertwined with microcode updates. > >Note: This should not grow the size of 'struct cpuinfo_x86' in >practice since the u8 fits next to another u8 in the structure. > >Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> >Cc: Thomas Gleixner <tglx@kernel.org> >Cc: Ingo Molnar <mingo@redhat.com> >Cc: Borislav Petkov <bp@alien8.de> >Cc: Dave Hansen <dave.hansen@linux.intel.com> >Cc: "H. Peter Anvin" <hpa@zytor.com> >Cc: Tony Luck <tony.luck@intel.com> >Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> >Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> >Cc: x86@kernel.org >Cc: Jon Kohler <jon@nutanix.com> >--- > > b/arch/x86/include/asm/processor.h | 1 + > b/arch/x86/kernel/cpu/common.c | 4 +++- > b/arch/x86/kernel/cpu/intel.c | 1 + > 3 files changed, 5 insertions(+), 1 deletion(-) > >diff -puN arch/x86/include/asm/processor.h~cpu-x86_stepping arch/x86/include/asm/processor.h >--- a/arch/x86/include/asm/processor.h~cpu-x86_stepping 2026-01-19 11:38:09.341914025 -0800 >+++ b/arch/x86/include/asm/processor.h 2026-01-19 11:38:09.444917962 -0800 >@@ -140,6 +140,7 @@ struct cpuinfo_x86 { > __u32 x86_vfm; > }; > __u8 x86_stepping; >+ __u8 x86_platform_id; /* Intel-only. 3 bits */ Tail comments are not preferred. I've seen tglx complain about them a few times. Also, "3 bits" is misleading since x86_platform_id actually stores a bit mask. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-20 3:14 ` Chao Gao @ 2026-01-20 15:22 ` Dave Hansen 2026-01-21 2:03 ` Chao Gao 0 siblings, 1 reply; 44+ messages in thread From: Dave Hansen @ 2026-01-20 15:22 UTC (permalink / raw) To: Chao Gao, 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/19/26 19:14, Chao Gao wrote: >> __u8 x86_stepping; >> + __u8 x86_platform_id; /* Intel-only. 3 bits */ > Tail comments are not preferred. I've seen tglx complain about them a few times. Yeah, you're right. It doesn't fit well with the rest of the structure. I'll fix it. > Also, "3 bits" is misleading since x86_platform_id actually stores a bit mask. Remember, there are two structures in play here. From the cover letter: > Treat the platform ID as a peer of model/family/stepping. Store it > in 'struct cpuinfo_x86', enable matching on it with with 'struct > x86_cpu_id', and flesh out the 'old_microcode' list with it. This hunk is patching 'cpuinfo_x86' which stores the 3 bits explicitly. I think you're thinking of the mask in 'x86_cpu_id' which is used for _matching_ this field in patch 5. Could you double check that you're asking about the right structure, please? I've certainly gotten the two structures mixed up before. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-20 15:22 ` Dave Hansen @ 2026-01-21 2:03 ` Chao Gao 0 siblings, 0 replies; 44+ messages in thread From: Chao Gao @ 2026-01-21 2:03 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:22:54AM -0800, Dave Hansen wrote: >On 1/19/26 19:14, Chao Gao wrote: >>> __u8 x86_stepping; >>> + __u8 x86_platform_id; /* Intel-only. 3 bits */ >> Tail comments are not preferred. I've seen tglx complain about them a few times. > >Yeah, you're right. It doesn't fit well with the rest of the structure. >I'll fix it. > >> Also, "3 bits" is misleading since x86_platform_id actually stores a bit mask. > >Remember, there are two structures in play here. From the cover letter: > >> Treat the platform ID as a peer of model/family/stepping. Store it >> in 'struct cpuinfo_x86', enable matching on it with with 'struct >> x86_cpu_id', and flesh out the 'old_microcode' list with it. > >This hunk is patching 'cpuinfo_x86' which stores the 3 bits explicitly. Hi Dave, This patch has: c->x86_platform_id = intel_get_platform_id(); but intel_get_platform_id() doesn't return the 3 bits; it returns a single-bit mask (or 0 on old CPUs). +static inline u32 intel_get_platform_id(void) +{ + unsigned int val[2]; + + /* + * This can be called early. Use CPUID directly to + * generate the VFM value for this CPU. + */ + if (intel_cpuid_vfm() < INTEL_PENTIUM_III_DESCHUTES) + return 0; + + /* get processor flags from MSR 0x17 */ + native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]); + return 1 << ((val[1] >> 18) & 7); +} > >I think you're thinking of the mask in 'x86_cpu_id' which is used for >_matching_ this field in patch 5. > >Could you double check that you're asking about the right structure, >please? I've certainly gotten the two structures mixed up before. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-19 19:50 ` [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen 2026-01-20 3:14 ` Chao Gao @ 2026-01-20 8:27 ` Andy Shevchenko 2026-01-20 15:06 ` Dave Hansen 1 sibling, 1 reply; 44+ messages in thread From: Andy Shevchenko @ 2026-01-20 8:27 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:55AM -0800, Dave Hansen wrote: > > The end goal here is to be able to do x86_match_cpu() and match on a > specific platform ID. While it would be possible to stash this ID > off somewhere or read it dynamically, that approaches would not be > consistent with the other fields which can be matched. > > Read the platform ID and store it in cpuinfo_x86->x86_platform_id. > > There are lots of sites to set this new field. Place it near > the place c->microcode is established since the platform ID is > so closely intertwined with microcode updates. > > Note: This should not grow the size of 'struct cpuinfo_x86' in > practice since the u8 fits next to another u8 in the structure. Have you run `pahole` to confirm? ... > c->x86_cache_size = 0; > c->x86_vendor = X86_VENDOR_UNKNOWN; > - c->x86_model = c->x86_stepping = 0; /* So far unknown... */ Shan't we preserve the comment? /* So far model, stepping, and platform_id are unknown... */ > + c->x86_model = 0; > + c->x86_stepping = 0; > + c->x86_platform_id = 0; > c->x86_vendor_id[0] = '\0'; /* Unset */ > c->x86_model_id[0] = '\0'; /* Unset */ -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-20 8:27 ` Andy Shevchenko @ 2026-01-20 15:06 ` Dave Hansen 2026-01-20 20:44 ` Andy Shevchenko 0 siblings, 1 reply; 44+ messages in thread From: Dave Hansen @ 2026-01-20 15:06 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:27, Andy Shevchenko wrote: ... >> Note: This should not grow the size of 'struct cpuinfo_x86' in >> practice since the u8 fits next to another u8 in the structure. > > Have you run `pahole` to confirm? I have not. If you'd like to contribute to the series by compiling this and running pahole on it, I'd very much appreciate it! > ... > >> c->x86_cache_size = 0; >> c->x86_vendor = X86_VENDOR_UNKNOWN; >> - c->x86_model = c->x86_stepping = 0; /* So far unknown... */ > > Shan't we preserve the comment? > > /* So far model, stepping, and platform_id are unknown... */ ... and cache size and vendor and everything else. It's not a super useful comment. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-20 15:06 ` Dave Hansen @ 2026-01-20 20:44 ` Andy Shevchenko 2026-01-20 20:48 ` Dave Hansen 0 siblings, 1 reply; 44+ messages in thread From: Andy Shevchenko @ 2026-01-20 20:44 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:06:56AM -0800, Dave Hansen wrote: > On 1/20/26 00:27, Andy Shevchenko wrote: > ... > >> Note: This should not grow the size of 'struct cpuinfo_x86' in > >> practice since the u8 fits next to another u8 in the structure. > > > > Have you run `pahole` to confirm? > > I have not. If you'd like to contribute to the series by compiling this > and running pahole on it, I'd very much appreciate it! Okay, here is the diff: --- old 2026-01-20 21:40:39.170530703 +0100 +++ new 2026-01-20 21:37:42.717138133 +0100 @@ -19,8 +19,9 @@ }; __u8 x86_stepping; /* 4 1 */ + __u8 x86_platform_id; /* 5 1 */ - /* XXX 3 bytes hole, try to pack */ + /* XXX 2 bytes hole, try to pack */ int x86_tlbsize; /* 8 4 */ __u32 vmx_capability[5]; /* 12 20 */ @@ -75,8 +76,8 @@ unsigned int initialized:1; /* 332: 8 4 */ - /* size: 336, cachelines: 6, members: 27 */ - /* sum members: 319, holes: 5, sum holes: 14 */ + /* size: 336, cachelines: 6, members: 28 */ + /* sum members: 320, holes: 5, sum holes: 13 */ /* sum bitfield members: 1 bits (0 bytes) */ /* bit_padding: 23 bits */ /* last cacheline: 16 bytes */ -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-20 20:44 ` Andy Shevchenko @ 2026-01-20 20:48 ` Dave Hansen 0 siblings, 0 replies; 44+ messages in thread From: Dave Hansen @ 2026-01-20 20:48 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 12:44, Andy Shevchenko wrote: > On Tue, Jan 20, 2026 at 07:06:56AM -0800, Dave Hansen wrote: >> On 1/20/26 00:27, Andy Shevchenko wrote: >> ... >>>> Note: This should not grow the size of 'struct cpuinfo_x86' in >>>> practice since the u8 fits next to another u8 in the structure. >>> Have you run `pahole` to confirm? >> I have not. If you'd like to contribute to the series by compiling this >> and running pahole on it, I'd very much appreciate it! > Okay, here is the diff: > > --- old 2026-01-20 21:40:39.170530703 +0100 > +++ new 2026-01-20 21:37:42.717138133 +0100 > @@ -19,8 +19,9 @@ > }; > > __u8 x86_stepping; /* 4 1 */ > + __u8 x86_platform_id; /* 5 1 */ Thanks a lot for verifying that! It appears that my built-in pahole is still working properly! Whew. ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure 2026-01-19 19:50 [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen ` (3 preceding siblings ...) 2026-01-19 19:50 ` [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen @ 2026-01-19 19:50 ` Dave Hansen 2026-01-20 8:30 ` Andy Shevchenko 2026-01-19 19:51 ` [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list Dave Hansen ` (2 subsequent siblings) 7 siblings, 1 reply; 44+ 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 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-01-19 11:38:10.020939979 -0800 +++ b/arch/x86/kernel/cpu/match.c 2026-01-19 11:38:10.046940973 -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 && + !(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-01-19 11:38:10.043940858 -0800 +++ b/include/linux/mod_devicetable.h 2026-01-19 11:38:10.046940973 -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] 44+ messages in thread
* Re: [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure 2026-01-19 19:50 ` [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure Dave Hansen @ 2026-01-20 8:30 ` Andy Shevchenko 2026-01-20 15:09 ` Dave Hansen 0 siblings, 1 reply; 44+ messages in thread From: Andy Shevchenko @ 2026-01-20 8:30 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:57AM -0800, Dave Hansen wrote: > 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. ... > 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; > }; ... > #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 */ Wouldn't it be slightly better to locate the new one here to follow the order in x86_cpu_id above? > #define X86_CPU_TYPE_ANY 0 -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure 2026-01-20 8:30 ` Andy Shevchenko @ 2026-01-20 15:09 ` Dave Hansen 0 siblings, 0 replies; 44+ messages in thread From: Dave Hansen @ 2026-01-20 15:09 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:30, Andy Shevchenko wrote: ... >> #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 */ > Wouldn't it be slightly better to locate the new one here to follow the order > in x86_cpu_id above? I stuck it there because ->platform_mask acts functionally like the stepping mask does. ^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list 2026-01-19 19:50 [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen ` (4 preceding siblings ...) 2026-01-19 19:50 ` [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure Dave Hansen @ 2026-01-19 19:51 ` Dave Hansen 2026-01-20 14:33 ` Zhao Liu 2026-01-29 21:23 ` Sohil Mehta 2026-01-20 18:18 ` [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen 2026-01-22 13:56 ` Ricardo Neri 7 siblings, 2 replies; 44+ messages in thread From: Dave Hansen @ 2026-01-19 19:51 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> 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") 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 | 368 +++++++++++---------- 1 file changed, 208 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-01-19 11:38:10.615962723 -0800 +++ b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h 2026-01-19 11:38:10.619962876 -0800 @@ -1,160 +1,208 @@ -{ .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 = 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 = 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 = 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 = 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 = 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 = 0x04, .driver_data = 0x2 }, +{ .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 = 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 = 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 = 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 = 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 = 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 = 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 = 0x87, .driver_data = 0x2b000639 }, +{ .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 = 0x0020, .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 = 0x0040, .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 = 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 = 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 = 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 = 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 = 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 = 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 = 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 = 0x10, .driver_data = 0x2c }, +{ .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 = 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 = 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 = 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 = 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] 44+ messages in thread
* Re: [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list 2026-01-19 19:51 ` [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list Dave Hansen @ 2026-01-20 14:33 ` Zhao Liu 2026-01-20 15:10 ` Dave Hansen 2026-01-29 21:23 ` Sohil Mehta 1 sibling, 1 reply; 44+ messages in thread From: Zhao Liu @ 2026-01-20 14:33 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:51:00AM -0800, Dave Hansen wrote: > Date: Mon, 19 Jan 2026 11:51:00 -0800 > From: Dave Hansen <dave.hansen@linux.intel.com> > Subject: [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode > "old" list > > > 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") > 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 | 368 +++++++++++---------- > 1 file changed, 208 insertions(+), 160 deletions(-) Reproduce the issue: On a SPR-SP (F-M-S: 06-8f-08) machine, update the microcode to the latest 20251111 release: * v6.19.0-rc6 (w/o this series): # dmesg | grep microcode [ 0.000000] x86/CPU: Running old microcode [ 20.400144] microcode: Current revision: 0x2b000650 [ 20.408038] microcode: Updated early from: 0x2b000461 * v6.19.0-rc6 (with this series): # dmesg | grep microcode [ 20.499999] microcode: Current revision: 0x2b000650 [ 20.507562] microcode: Updated early from: 0x2b000461 The false positive complain about old microcode is fixed on my machine. So, Tested-by: Zhao Liu <zhao1.liu@intel.com> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list 2026-01-20 14:33 ` Zhao Liu @ 2026-01-20 15:10 ` Dave Hansen 0 siblings, 0 replies; 44+ messages in thread From: Dave Hansen @ 2026-01-20 15:10 UTC (permalink / raw) To: Zhao Liu, 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 06:33, Zhao Liu wrote: ... > Tested-by: Zhao Liu <zhao1.liu@intel.com> Thanks for testing this! ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list 2026-01-19 19:51 ` [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list Dave Hansen 2026-01-20 14:33 ` Zhao Liu @ 2026-01-29 21:23 ` Sohil Mehta 1 sibling, 0 replies; 44+ messages in thread From: Sohil Mehta @ 2026-01-29 21:23 UTC (permalink / raw) To: Dave Hansen Cc: Borislav Petkov, H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel), Thomas Gleixner, Tony Luck, x86, LKML Mailing List On 1/19/2026 11:51 AM, Dave Hansen wrote: > > 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. > There is an issue in the newly generated list, likely due to a bug in the generation script. I noticed that some entries are missing. For example, models 0x46 (Haswell_G) and 0xbe (Alderlake) get deleted in the diff but do not have a corresponding new entry in the list with platform ID. Deleted ones: > -{ .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 = 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 }, Added with platform IDs, but no model 0x46 or 0xbe: > +{ .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 = 0x47, .steppings = 0x0002, .platform_mask = 0x22, .driver_data = 0x22 }, > +{ .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 = 0xbf, .steppings = 0x0004, .platform_mask = 0x07, .driver_data = 0x3a }, ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks 2026-01-19 19:50 [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen ` (5 preceding siblings ...) 2026-01-19 19:51 ` [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list Dave Hansen @ 2026-01-20 18:18 ` Dave Hansen 2026-01-22 13:56 ` Ricardo Neri 7 siblings, 0 replies; 44+ messages in thread From: Dave Hansen @ 2026-01-20 18:18 UTC (permalink / raw) To: Dave Hansen, linux-kernel Cc: sohil.mehta, Borislav Petkov, H. Peter Anvin, Ingo Molnar, Jon Kohler, Pawan Gupta, Peter Zijlstra (Intel), Thomas Gleixner, Tony Luck, x86 On 1/19/26 11:50, Dave Hansen wrote: > This fixes the report of an inaccurate, false positive in the > 'old_microcode' vulnerability file. BTW... I'm open to other ways of fixing this. This series is bigger than I'd like. It also crept into silly areas like the PECI driver, which isn't great. Using the x86_match_cpu() infrastructure means both munging the existing, widely-used 'x86_cpu_id' and 'cpuinfo_x86' structures ... all for what is essentially a single user. But, the overhead is minimal because both structures had some holes and the platform_id is small. It might also have been possible to cram the microcode revision and platform ID into the ->driver_data in cpu_latest_microcode[]. But that would not have been straightforward on 32-bit since the kernel_ulong_t driver_data is full with the microcode revision. Anyone have any better ideas? ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks 2026-01-19 19:50 [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen ` (6 preceding siblings ...) 2026-01-20 18:18 ` [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen @ 2026-01-22 13:56 ` Ricardo Neri 7 siblings, 0 replies; 44+ messages in thread From: Ricardo Neri @ 2026-01-22 13:56 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:47AM -0800, Dave Hansen wrote: > 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/ I tested this patchset on two machines: Alder Lake (F-M-S/PI = 06-9a-04/80). The microcode-20251111 from Intel lists different versions for platform IDs 0x80 and 0x40 of 06-9a-04. Before these patches, only the machine with platform ID 0x40 would have falsely complained about the old microcode. Mine did not, as expected. I applied this patchset and tweaked the file intel-ucode-defs.h to fake a later microcode version. I could verify that my machine was identified correctly and distinguished from 06-9a-04/40. Kaby Lake (F-M-S/PI = 06-8e-09/80). There are two platform IDs for this model and stepping, but the latest microcode for both is 0xf6. Neither of these processors would have reproduced the reported false positive. Again, I tweaked intel-ucode-defs.h with a fake .data_driver value and could verify that my stepping and platform ID were identified correctly. Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure
@ 2026-01-20 14:34 Maciej Wieczor-Retman
2026-01-20 15:13 ` Dave Hansen
0 siblings, 1 reply; 44+ messages in thread
From: Maciej Wieczor-Retman @ 2026-01-20 14:34 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 2026-01-19 at 11:50:55 -0800, Dave Hansen wrote:
>
>From: Dave Hansen <dave.hansen@linux.intel.com>
>
>The end goal here is to be able to do x86_match_cpu() and match on a
>specific platform ID. While it would be possible to stash this ID
>off somewhere or read it dynamically, that approaches would not be
>consistent with the other fields which can be matched.
>
>Read the platform ID and store it in cpuinfo_x86->x86_platform_id.
>
>There are lots of sites to set this new field. Place it near
>the place c->microcode is established since the platform ID is
>so closely intertwined with microcode updates.
>
>Note: This should not grow the size of 'struct cpuinfo_x86' in
>practice since the u8 fits next to another u8 in the structure.
>
>Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>Cc: Thomas Gleixner <tglx@kernel.org>
>Cc: Ingo Molnar <mingo@redhat.com>
>Cc: Borislav Petkov <bp@alien8.de>
>Cc: Dave Hansen <dave.hansen@linux.intel.com>
>Cc: "H. Peter Anvin" <hpa@zytor.com>
>Cc: Tony Luck <tony.luck@intel.com>
>Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
>Cc: x86@kernel.org
>Cc: Jon Kohler <jon@nutanix.com>
>---
>
> b/arch/x86/include/asm/processor.h | 1 +
> b/arch/x86/kernel/cpu/common.c | 4 +++-
> b/arch/x86/kernel/cpu/intel.c | 1 +
> 3 files changed, 5 insertions(+), 1 deletion(-)
>
>diff -puN arch/x86/include/asm/processor.h~cpu-x86_stepping arch/x86/include/asm/processor.h
>--- a/arch/x86/include/asm/processor.h~cpu-x86_stepping 2026-01-19 11:38:09.341914025 -0800
>+++ b/arch/x86/include/asm/processor.h 2026-01-19 11:38:09.444917962 -0800
>@@ -140,6 +140,7 @@ struct cpuinfo_x86 {
> __u32 x86_vfm;
> };
> __u8 x86_stepping;
>+ __u8 x86_platform_id; /* Intel-only. 3 bits */
Should platform ID be added to print_cpu_info()?
So it's printed alongside (family: 0xN model: 0xN, stepping: 0xN)
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-20 14:34 [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Maciej Wieczor-Retman @ 2026-01-20 15:13 ` Dave Hansen 2026-01-20 16:03 ` Maciej Wieczor-Retman 0 siblings, 1 reply; 44+ messages in thread From: Dave Hansen @ 2026-01-20 15:13 UTC (permalink / raw) To: Maciej Wieczor-Retman, 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 06:34, Maciej Wieczor-Retman wrote: >> __u8 x86_stepping; >> + __u8 x86_platform_id; /* Intel-only. 3 bits */ > Should platform ID be added to print_cpu_info()? > > So it's printed alongside (family: 0xN model: 0xN, stepping: 0xN) It's not a horrible idea, but it's also relatively worthless compared to the other three. I'd certainly take a look at it if someone sent a patch, but I'm not really looking to add more to this series that doesn't _need_ to be here. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-20 15:13 ` Dave Hansen @ 2026-01-20 16:03 ` Maciej Wieczor-Retman 2026-01-20 16:12 ` Dave Hansen 0 siblings, 1 reply; 44+ messages in thread From: Maciej Wieczor-Retman @ 2026-01-20 16:03 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 2026-01-20 at 07:13:31 -0800, Dave Hansen wrote: >On 1/20/26 06:34, Maciej Wieczor-Retman wrote: >>> __u8 x86_stepping; >>> + __u8 x86_platform_id; /* Intel-only. 3 bits */ >> Should platform ID be added to print_cpu_info()? >> >> So it's printed alongside (family: 0xN model: 0xN, stepping: 0xN) > >It's not a horrible idea, but it's also relatively worthless compared to >the other three. I'd certainly take a look at it if someone sent a >patch, but I'm not really looking to add more to this series that >doesn't _need_ to be here. Fair enough, and I suppose if someone really needs this information they can just read the MSR themselves. -- Kind regards Maciej Wieczór-Retman ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure 2026-01-20 16:03 ` Maciej Wieczor-Retman @ 2026-01-20 16:12 ` Dave Hansen 0 siblings, 0 replies; 44+ messages in thread From: Dave Hansen @ 2026-01-20 16:12 UTC (permalink / raw) To: Maciej Wieczor-Retman 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:03, Maciej Wieczor-Retman wrote: > On 2026-01-20 at 07:13:31 -0800, Dave Hansen wrote: >> On 1/20/26 06:34, Maciej Wieczor-Retman wrote: >>>> __u8 x86_stepping; >>>> + __u8 x86_platform_id; /* Intel-only. 3 bits */ >>> Should platform ID be added to print_cpu_info()? >>> >>> So it's printed alongside (family: 0xN model: 0xN, stepping: 0xN) >> It's not a horrible idea, but it's also relatively worthless compared to >> the other three. I'd certainly take a look at it if someone sent a >> patch, but I'm not really looking to add more to this series that >> doesn't _need_ to be here. > Fair enough, and I suppose if someone really needs this information they can > just read the MSR themselves. Right. If they get some weird "old_microcode" output, they can go use rdmsr(1) to debug it if they're root. It might make debugging issues a _wee_ bit easier to have the platform_id in dmesg, but it's only used in two places in the kernel, so the value is *MUCH* lower than family/model/stepping which are used all over. Also, despite being 6 patches, this series is _just_ about as small as I can make it to fix the bug at hand. Even if we decided a pr_whatever() would be really nice, it's not a bug fix and would (IMNHO) need to be in a separate series. ^ permalink raw reply [flat|nested] 44+ messages in thread
* [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 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen 0 siblings, 1 reply; 44+ 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] 44+ 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 @ 2026-02-06 23:14 ` Dave Hansen 2026-02-08 21:37 ` Borislav Petkov 2026-02-10 23:23 ` Sohil Mehta 0 siblings, 2 replies; 44+ 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] 44+ 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; 44+ 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] 44+ 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; 44+ 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] 44+ 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; 44+ 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] 44+ 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; 44+ 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] 44+ messages in thread
end of thread, other threads:[~2026-02-12 15:22 UTC | newest] Thread overview: 44+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-01-19 19:50 [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks 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 2026-01-19 19:50 ` [PATCH 2/6] x86/cpu: Add missing #include Dave Hansen 2026-01-20 0:26 ` Dave Hansen 2026-01-20 8:19 ` Andy Shevchenko 2026-01-20 15:35 ` Dave Hansen 2026-01-19 19:50 ` [PATCH 3/6] x86/microcode: Refactor platform ID enumeration into a helper Dave Hansen 2026-01-20 3:07 ` Chao Gao 2026-01-20 16:06 ` Dave Hansen 2026-01-20 20:59 ` Andy Shevchenko 2026-01-22 19:26 ` Sohil Mehta 2026-01-19 19:50 ` [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Dave Hansen 2026-01-20 3:14 ` Chao Gao 2026-01-20 15:22 ` Dave Hansen 2026-01-21 2:03 ` Chao Gao 2026-01-20 8:27 ` Andy Shevchenko 2026-01-20 15:06 ` Dave Hansen 2026-01-20 20:44 ` Andy Shevchenko 2026-01-20 20:48 ` Dave Hansen 2026-01-19 19:50 ` [PATCH 5/6] x86/cpu: Add platform ID to CPU matching structure Dave Hansen 2026-01-20 8:30 ` Andy Shevchenko 2026-01-20 15:09 ` Dave Hansen 2026-01-19 19:51 ` [PATCH 6/6] x86/microcode: Add platform mask to Intel microcode "old" list Dave Hansen 2026-01-20 14:33 ` Zhao Liu 2026-01-20 15:10 ` Dave Hansen 2026-01-29 21:23 ` Sohil Mehta 2026-01-20 18:18 ` [PATCH 0/6] x86/cpu: Take Intel platform into account for old microcode checks Dave Hansen 2026-01-22 13:56 ` Ricardo Neri -- strict thread matches above, loose matches on Subject: below -- 2026-01-20 14:34 [PATCH 4/6] x86/cpu: Add platform ID to CPU info structure Maciej Wieczor-Retman 2026-01-20 15:13 ` Dave Hansen 2026-01-20 16:03 ` Maciej Wieczor-Retman 2026-01-20 16:12 ` Dave Hansen 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox