Update the minimum expected revisions of Intel microcode based on the
microcode-20250512 (May 2025) release.
Cc: <stable@kernel.org> # v6.15+
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
.../kernel/cpu/microcode/intel-ucode-defs.h | 86 +++++++++++--------
1 file changed, 48 insertions(+), 38 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
index cb6e601701ab..2d48e6593540 100644
--- a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
+++ b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
@@ -67,9 +67,8 @@
{ .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 = 0x0040, .driver_data = 0x4003605 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0080, .driver_data = 0x5003707 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0800, .driver_data = 0x7002904 },
+{ .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 },
@@ -81,51 +80,62 @@
{ .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 = 0xd0003e7 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x6c, .steppings = 0x0002, .driver_data = 0x10002b0 },
+{ .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 = 0x24 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7e, .steppings = 0x0020, .driver_data = 0xc6 },
+{ .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 = 0xb8 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8c, .steppings = 0x0004, .driver_data = 0x38 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8d, .steppings = 0x0002, .driver_data = 0x52 },
+{ .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 = 0xfc },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0100, .driver_data = 0x2c000390 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0080, .driver_data = 0x2b000603 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0040, .driver_data = 0x2c000390 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0020, .driver_data = 0x2c000390 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0010, .driver_data = 0x2c000390 },
+{ .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 = 0x37 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x97, .steppings = 0x0020, .driver_data = 0x37 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbf, .steppings = 0x0004, .driver_data = 0x37 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbf, .steppings = 0x0020, .driver_data = 0x37 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9a, .steppings = 0x0008, .driver_data = 0x435 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x9a, .steppings = 0x0010, .driver_data = 0x435 },
+{ .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 = 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 = 0x100 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa5, .steppings = 0x0004, .driver_data = 0xfc },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa5, .steppings = 0x0008, .driver_data = 0xfc },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa5, .steppings = 0x0020, .driver_data = 0xfc },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa6, .steppings = 0x0001, .driver_data = 0xfe },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa6, .steppings = 0x0002, .driver_data = 0xfc },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xa7, .steppings = 0x0002, .driver_data = 0x62 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xaa, .steppings = 0x0010, .driver_data = 0x20 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xb7, .steppings = 0x0002, .driver_data = 0x12b },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xba, .steppings = 0x0004, .driver_data = 0x4123 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xba, .steppings = 0x0008, .driver_data = 0x4123 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xba, .steppings = 0x0100, .driver_data = 0x4123 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xbe, .steppings = 0x0001, .driver_data = 0x1a },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xcf, .steppings = 0x0004, .driver_data = 0x21000283 },
-{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0xcf, .steppings = 0x0002, .driver_data = 0x21000283 },
+{ .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 },
--
2.43.0On Mon, Aug 18, 2025 at 12:01:36PM -0700, Sohil Mehta wrote:
> Update the minimum expected revisions of Intel microcode based on the
> microcode-20250512 (May 2025) release.
>
> Cc: <stable@kernel.org> # v6.15+
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> ---
> .../kernel/cpu/microcode/intel-ucode-defs.h | 86 +++++++++++--------
> 1 file changed, 48 insertions(+), 38 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
> index cb6e601701ab..2d48e6593540 100644
> --- a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
> +++ b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
> @@ -67,9 +67,8 @@
> { .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 = 0x0040, .driver_data = 0x4003605 },
".model = 0x55, .steppings = 0x0040" is being removed? Total number of
entries in the table are being reduced by ~10.
> -{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0080, .driver_data = 0x5003707 },
> -{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x55, .steppings = 0x0800, .driver_data = 0x7002904 },
> +{ .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 },
> @@ -81,51 +80,62 @@
On 19/08/2025 6:19 am, Pawan Gupta wrote:
> On Mon, Aug 18, 2025 at 12:01:36PM -0700, Sohil Mehta wrote:
>> Update the minimum expected revisions of Intel microcode based on the
>> microcode-20250512 (May 2025) release.
>>
>> Cc: <stable@kernel.org> # v6.15+
>> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
>> ---
>> .../kernel/cpu/microcode/intel-ucode-defs.h | 86 +++++++++++--------
>> 1 file changed, 48 insertions(+), 38 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
>> index cb6e601701ab..2d48e6593540 100644
>> --- a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
>> +++ b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
>> @@ -67,9 +67,8 @@
>> { .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 = 0x0040, .driver_data = 0x4003605 },
> ".model = 0x55, .steppings = 0x0040" is being removed? Total number of
> entries in the table are being reduced by ~10.
That's because early in a CPUs lifecycle, microcode for the late
pre-production steppings are still included in the public repo, but
eventually dropped.
Alas, these deletions are documented as well as everything else is in
the changelog...
~Andrew
On Tue, Aug 19, 2025 at 12:18:45PM +0100, Andrew Cooper wrote:
> On 19/08/2025 6:19 am, Pawan Gupta wrote:
> > On Mon, Aug 18, 2025 at 12:01:36PM -0700, Sohil Mehta wrote:
> >> Update the minimum expected revisions of Intel microcode based on the
> >> microcode-20250512 (May 2025) release.
> >>
> >> Cc: <stable@kernel.org> # v6.15+
> >> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> >> ---
> >> .../kernel/cpu/microcode/intel-ucode-defs.h | 86 +++++++++++--------
> >> 1 file changed, 48 insertions(+), 38 deletions(-)
> >>
> >> diff --git a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
> >> index cb6e601701ab..2d48e6593540 100644
> >> --- a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
> >> +++ b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
> >> @@ -67,9 +67,8 @@
> >> { .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 = 0x0040, .driver_data = 0x4003605 },
> > ".model = 0x55, .steppings = 0x0040" is being removed? Total number of
> > entries in the table are being reduced by ~10.
>
> That's because early in a CPUs lifecycle, microcode for the late
> pre-production steppings are still included in the public repo, but
> eventually dropped.
Sometimes Linux care about the pre-production steppings, other times we
don't.
> Alas, these deletions are documented as well as everything else is in
> the changelog...
Should this file reflect those deletions as well? As an example, if an
ancient part gets removed from the microcode repo, it may still be worth
for Linux to keep the record of its last microcode version.
On 8/19/25 11:28, Pawan Gupta wrote: >> Alas, these deletions are documented as well as everything else is in >> the changelog... > Should this file reflect those deletions as well? As an example, if an > ancient part gets removed from the microcode repo, it may still be worth > for Linux to keep the record of its last microcode version. <sigh> There's even a "Removed Platforms" section in the microcode repo changelogs that gets copied and pasted for each release. But it's not consistently updated as platforms are removed. But, thanks to the magic of git, we can just look for the removed files: 06-55-06 06-cf-01 06-8f-05 06-8f-06 06-ba-08 06-8f-04 06-86-04 06-86-05 .. that never came back in a later version. It might be a fun exercise to run through those and see if any of them matter. We could always reconstruct the .h file from *all* of the microcode repo's git history. It's just scripting. But we better be doing it for a real reason. If folks have one of these preproduction CPUs, they've got much bigger problems that being warned about old microcode. If we think it's the kernel's job to tell folks about these, I'd rather it be some other mechanism than the old_microcode one. For instance, we could make a x86_cpu_id[] that lists these and taints if they're ever seen. So, let's just ignore this issue for now. I'm not convinced it's a practical problem.
On 19/08/2025 8:07 pm, Dave Hansen wrote: > On 8/19/25 11:28, Pawan Gupta wrote: >>> Alas, these deletions are documented as well as everything else is in >>> the changelog... >> Should this file reflect those deletions as well? As an example, if an >> ancient part gets removed from the microcode repo, it may still be worth >> for Linux to keep the record of its last microcode version. > <sigh> > > There's even a "Removed Platforms" section in the microcode repo > changelogs that gets copied and pasted for each release. But it's not > consistently updated as platforms are removed. > > But, thanks to the magic of git, we can just look for the removed files: > > 06-55-06 CLX B0 stepping, notably gaining MSR_TSX_FORCE_ABORT rather than MSR_TSX_CTRL. It was a giant muddle for mitigations. > 06-cf-01 EMR. Stepping 2 still available. > 06-8f-04 > 06-8f-05 > 06-8f-06 SPR. Steppings 7 and 8 still available. These are weird. 06-8f-08 has two blobs in it with disjoint platform flags (this is fine). However, all 3 blobs between -07 and -08 all have sigtables covering everything back to stepping 4. Arguably that's a bug for the intel form of the microcode (which is indexed on stepping), but it's just some extraneous metadata. The rest of it is suggesting that SPR steppings 4-8 had compatible-enough microcode for them all to be patched by the same blob. > 06-ba-08 RPL. The repo has steppings 2 and 3, so I wonder what RPL stepping 8 is. > 06-86-04 > 06-86-05 SNR. All steppings dropped, although it's apparently a mobile basestation only, so I guess it's not running Linux. ~Andrew
On 8/19/2025 4:18 AM, Andrew Cooper wrote: > On 19/08/2025 6:19 am, Pawan Gupta wrote: >> On Mon, Aug 18, 2025 at 12:01:36PM -0700, Sohil Mehta wrote: >>> Update the minimum expected revisions of Intel microcode based on the >>> microcode-20250512 (May 2025) release. >>> >>> Cc: <stable@kernel.org> # v6.15+ >>> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com> >>> --- >>> .../kernel/cpu/microcode/intel-ucode-defs.h | 86 +++++++++++-------- >>> 1 file changed, 48 insertions(+), 38 deletions(-) >>> >> ".model = 0x55, .steppings = 0x0040" is being removed? Total number of >> entries in the table are being reduced by ~10. > Based on the diff stat, aren't the total entries increasing by 10? > That's because early in a CPUs lifecycle, microcode for the late > pre-production steppings are still included in the public repo, but > eventually dropped. > > Alas, these deletions are documented as well as everything else is in > the changelog... > I sorted the file by FMS to make it easier to spot changes going forward. Though, I don't think we can rely on the kernel history to track the microcode changes. Because there isn't a direct 1:1 mapping between the microcode releases and the kernel update. (Unless that's what you are proposing) Dave's initial commit used the Nov 2024 release, and this one is based on May 2025. There could potentially be multiple releases in the middle that added and removed stuff which would go unnoticed. Though, using the script in patch 2 it should be easy to track that (outside the kernel) if really needed. > ~Andrew
On Tue, Aug 19, 2025 at 09:13:27AM -0700, Sohil Mehta wrote: > On 8/19/2025 4:18 AM, Andrew Cooper wrote: > > On 19/08/2025 6:19 am, Pawan Gupta wrote: > >> On Mon, Aug 18, 2025 at 12:01:36PM -0700, Sohil Mehta wrote: > >>> Update the minimum expected revisions of Intel microcode based on the > >>> microcode-20250512 (May 2025) release. > >>> > >>> Cc: <stable@kernel.org> # v6.15+ > >>> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com> > >>> --- > >>> .../kernel/cpu/microcode/intel-ucode-defs.h | 86 +++++++++++-------- > >>> 1 file changed, 48 insertions(+), 38 deletions(-) > >>> > >> ".model = 0x55, .steppings = 0x0040" is being removed? Total number of > >> entries in the table are being reduced by ~10. > > > > Based on the diff stat, aren't the total entries increasing by 10? Ya, sorry my bad.
> On Aug 18, 2025, at 3:01 PM, Sohil Mehta <sohil.mehta@intel.com> wrote:
>
> Update the minimum expected revisions of Intel microcode based on the
> microcode-20250512 (May 2025) release.
>
> Cc: <stable@kernel.org> # v6.15+
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> ---
> .../kernel/cpu/microcode/intel-ucode-defs.h | 86 +++++++++++--------
> 1 file changed, 48 insertions(+), 38 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
> index cb6e601701ab..2d48e6593540 100644
> --- a/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
> +++ b/arch/x86/kernel/cpu/microcode/intel-ucode-defs.h
> @@ -67,9 +67,8 @@
> … snip …
> -{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0100, .driver_data = 0x2c000390 },
> -{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0080, .driver_data = 0x2b000603 },
> -{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0040, .driver_data = 0x2c000390 },
> -{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0020, .driver_data = 0x2c000390 },
> -{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x8f, .steppings = 0x0010, .driver_data = 0x2c000390 },
> +{ .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 },
> … snip …
Hi LKML, Dave, Sohil,
Wanted to report a CPU matching issue I'm seeing on one of our SPR
hosts, which results in it being flagged for old microcode, despite
having the latest microcode early loaded.
Using 6.18 rc2 plus the latest newer microcode loaded from the Intel
20250812 release, it seems like this is matching a different stepping
so the CPU is getting flagged as old.
Added a bit of logging prefixed with JKDBG:
[ 0.000000] microcode: JKDBG: about to load microcode (BSP)
[ 0.000000] microcode: JKDBG: microcode loaded (BSP): 0x2b000643
[ 0.000000] x86/CPU: JKDBG: MATCH microcode list entry: family 0x6, model 0x8f, steppings 0x100
[ 0.000000] x86/CPU: JKDBG: BOOT_CPU_DATA family 0x6, model 0x8f, stepping 0x8
[ 0.000000] x86/CPU: JKDBG: microcode is older than latest available: current 0x2b000643, latest 0x2c0003f7
[ 0.000000] x86/CPU: Running old microcode
...
[ 2.521338] smpboot: CPU0: Intel(R) Xeon(R) Gold 5416S (family: 0x6, model: 0x8f, stepping: 0x8)
...
[ 3.593063] microcode: Current revision: 0x2b000643
[ 3.593065] microcode: Updated early from: 0x2b0004b1
I reverted this patch, and also got the same matching, so it isn't
regressed in 6.18, it just doesn't match like I'd expect. The microcode
updater itself seems to work a-ok though.
With revert:
[ 0.000000] microcode: JKDBG: about to load microcode (BSP)
[ 0.000000] microcode: JKDBG: microcode loaded (BSP): 0x2b000643
[ 0.000000] x86/CPU: JKDBG: MATCH microcode list entry: family 0x6, model 0x8f, steppings 0x100
[ 0.000000] x86/CPU: JKDBG: BOOT_CPU_DATA family 0x6, model 0x8f, stepping 0x8
[ 0.000000] x86/CPU: JKDBG: microcode is older than latest available: current 0x2b000643, latest 0x2c000390
[ 0.000000] x86/CPU: Running old microcode
...
[ 4.448770] microcode: Current revision: 0x2b000643
[ 4.448772] microcode: Updated early from: 0x2b0004b1
Looking at the microcode release notes, I believe I’m supposed to be
hitting SPR-SP 06-8f-08/87:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20250812
What the matching code is coming up with though is Xeon Max,
which I definitely am not running in my lab host.
Happy to collaborate on debugging if you’d like any more
data points.
- Jon
I think this is a platform mismatch problem. The microcode file for 06-8f-08 has two different versions for two different platforms: $ iucode-tool --list-all intel-ucode/06-8f-08 ... sig 0x000806f8, pf_mask 0x10, 2025-04-08, rev 0x2c000401 ... sig 0x000806f8, pf_mask 0x87, 2025-04-04, rev 0x2b000643 Note the pf_mask and rev deltas here: ^^^^ ^^^^^^^^^^ I guess we'll need to take those into consideration, both adding pf_mask to the match list and actually matching on it.
On 10/22/25 10:53, Dave Hansen wrote: > I think this is a platform mismatch problem. The microcode file for > 06-8f-08 has two different versions for two different platforms: > > $ iucode-tool --list-all intel-ucode/06-8f-08 > ... > sig 0x000806f8, pf_mask 0x10, 2025-04-08, rev 0x2c000401 > ... > sig 0x000806f8, pf_mask 0x87, 2025-04-04, rev 0x2b000643 > > Note the pf_mask and rev deltas here: ^^^^ ^^^^^^^^^^ > > I guess we'll need to take those into consideration, both adding pf_mask to > the match list and actually matching on it. Jon, Here is a completely untested series that might fix your issue: https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=old-ucode-platform It attempts to take IA32_PLATFORM_ID into account when considering old microcode.
> On Nov 14, 2025, at 3:34 PM, Dave Hansen <dave.hansen@intel.com> wrote: > > On 10/22/25 10:53, Dave Hansen wrote: >> I think this is a platform mismatch problem. The microcode file for >> 06-8f-08 has two different versions for two different platforms: >> >> $ iucode-tool --list-all intel-ucode/06-8f-08 >> ... >> sig 0x000806f8, pf_mask 0x10, 2025-04-08, rev 0x2c000401 >> ... >> sig 0x000806f8, pf_mask 0x87, 2025-04-04, rev 0x2b000643 >> >> Note the pf_mask and rev deltas here: ^^^^ ^^^^^^^^^^ >> >> I guess we'll need to take those into consideration, both adding pf_mask to >> the match list and actually matching on it. > > Jon, > > Here is a completely untested series that might fix your issue: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_daveh_devel.git_log_-3Fh-3Dold-2Ducode-2Dplatform&d=DwICaQ&c=s883GpUCOChKOHiocYtGcg&r=NGPRGGo37mQiSXgHKm5rCQ&m=4zPePvFxfJXfp66SgLg_V32bsZLtf6acUOdSXGiOs7nHYrGTY8wvYIsVMdQwGguK&s=RASYUF-4djrYzQOFmSzkZbzpoWsg_qsGHiQJMcLGVhw&e= > > It attempts to take IA32_PLATFORM_ID into account when considering > old microcode. Hey Dave - got a chance to give it a go, and this did not seem to solve the issue, and in fact it made it kinda worse as I didn’t end up seeing the microcode getting patched up at all now. On 6.18 rc6 with a bit of debug logging added, still seeing the same [ 0.000000] x86/CPU: microcode 0x721421856 is older than minimum 0x721421881 [ 0.000000] x86/CPU: MATCH LIST DATA: family 0x6, model 0x8f, steppings 0x100 [ 0.000000] x86/CPU: BOOT_CPU_DATA: family 0x6, model 0x8f, stepping 0x8 [ 0.000000] x86/CPU: Running old microcode [ 3.404176] microcode: Current revision: 0x2b000620 <<<<< I do have 0x2b000643 on the system, but it didn’t give me a notice that it updated early now This was on this proc: smpboot: CPU0: Intel(R) Xeon(R) Gold 5416S (family: 0x6, model: 0x8f, stepping: 0x8) Jon
On 11/20/2025 8:35 AM, Jon Kohler wrote: >> >> It attempts to take IA32_PLATFORM_ID into account when considering >> old microcode. > > Hey Dave - got a chance to give it a go, and this did not seem to solve > the issue, and in fact it made it kinda worse as I didn’t end up seeing > the microcode getting patched up at all now. > There seems to be a simple bug in the patches. intel_get_platform_id() already returns a mask so x86_match_cpu() shouldn't do the BIT() operation for the platform_id. Ignoring variable renames, this change (ontop of the patches) should atleast fix the x86_match_cpu() issue. diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c index 23b13ffc6053..613860448855 100644 --- a/arch/x86/kernel/cpu/match.c +++ b/arch/x86/kernel/cpu/match.c @@ -77,7 +77,7 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match) !(BIT(c->x86_stepping) & m->steppings)) continue; if (m->platform_mask != X86_PLATFORM_ANY && - !(BIT(c->x86_platform_id) & m->platform_mask)) + !(c->x86_platform_id & m->platform_mask)) continue; if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature)) continue; > On 6.18 rc6 with a bit of debug logging added, still seeing the same > > [ 0.000000] x86/CPU: microcode 0x721421856 is older than minimum 0x721421881 > [ 0.000000] x86/CPU: MATCH LIST DATA: family 0x6, model 0x8f, steppings 0x100 > [ 0.000000] x86/CPU: BOOT_CPU_DATA: family 0x6, model 0x8f, stepping 0x8 > [ 0.000000] x86/CPU: Running old microcode > [ 3.404176] microcode: Current revision: 0x2b000620 <<<<< I do have 0x2b000643 on the system, but it didn’t give me a notice that it updated early now > > This was on this proc: > smpboot: CPU0: Intel(R) Xeon(R) Gold 5416S (family: 0x6, model: 0x8f, stepping: 0x8) > > Jon
On 11/20/2025 9:29 AM, Sohil Mehta wrote:
> diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c
> index 23b13ffc6053..613860448855 100644
> --- a/arch/x86/kernel/cpu/match.c
> +++ b/arch/x86/kernel/cpu/match.c
> @@ -77,7 +77,7 @@ const struct x86_cpu_id *x86_match_cpu(const struct
> x86_cpu_id *match)
> !(BIT(c->x86_stepping) & m->steppings))
> continue;
> if (m->platform_mask != X86_PLATFORM_ANY &&
> - !(BIT(c->x86_platform_id) & m->platform_mask))
> + !(c->x86_platform_id & m->platform_mask))
> continue;
> if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
> continue;
>
>
>> On 6.18 rc6 with a bit of debug logging added, still seeing the same
>>
>> [ 0.000000] x86/CPU: microcode 0x721421856 is older than minimum 0x721421881
>> [ 0.000000] x86/CPU: MATCH LIST DATA: family 0x6, model 0x8f, steppings 0x100
>> [ 0.000000] x86/CPU: BOOT_CPU_DATA: family 0x6, model 0x8f, stepping 0x8
>> [ 0.000000] x86/CPU: Running old microcode
>> [ 3.404176] microcode: Current revision: 0x2b000620 <<<<< I do have 0x2b000643 on the system, but it didn’t give me a notice that it updated early now
>>
>
The early loading probably gets affected because intel_get_platform_id()
relies on boot_cpu_data which isn't initialized when load_ucode_bsp() is
called very early.
As you are clearly not running on a 25 year old processor maybe comment
out the INTEL_PENTIUM_III_DESCHUTES check as below just for testing :)
diff --git a/arch/x86/include/asm/microcode.h
b/arch/x86/include/asm/microcode.h
index 6ec2d78c78f0..c1950902a593 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -81,8 +81,8 @@ static inline u32 intel_get_platform_id(void)
{
unsigned int val[2];
- if (boot_cpu_data.x86_vfm < INTEL_PENTIUM_III_DESCHUTES)
- return 0;
+ // if (boot_cpu_data.x86_vfm < INTEL_PENTIUM_III_DESCHUTES)
+ // return 0;
/* get processor flags from MSR 0x17 */
native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]);
Both my suggestions are mainly to unblock your testing. An upstreamable
fix would need some additional rework.
>> This was on this proc:
>> smpboot: CPU0: Intel(R) Xeon(R) Gold 5416S (family: 0x6, model: 0x8f, stepping: 0x8)
On 11/20/25 11:13, Sohil Mehta wrote: > The early loading probably gets affected because intel_get_platform_id() > relies on boot_cpu_data which isn't initialized when load_ucode_bsp() is > called very early. Good point, and thanks for finding those bugs! We can probably just move back to building the vfm value from CPUID directly as opposed to reading it from boot_cpu_data.
On 11/20/25 11:27, Dave Hansen wrote:
> On 11/20/25 11:13, Sohil Mehta wrote:
>> The early loading probably gets affected because intel_get_platform_id()
>> relies on boot_cpu_data which isn't initialized when load_ucode_bsp() is
>> called very early.
> Good point, and thanks for finding those bugs!
>
> We can probably just move back to building the vfm value from CPUID
> directly as opposed to reading it from boot_cpu_data.
OK, here's a theoretically fixed up series. I actually booted this on
real hardware and made sure I didn't break microcode loading in general:
https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=old-ucode-platform
The actual hardware I tested on was this one:
{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7a, .steppings = 0x0002, .platform_mask = 0x01, .driver_data = 0x42 },
For testing, I added a 100% made up but matching CPU
model/family/stepping that has (made up) later microcode and a
(made up) higher platform ID that I added to the ucode-defs.h file:
{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7a, .steppings = 0x0002, .platform_mask = 0x02, .driver_data = 0x43 },
Everything seemed to work OK for me in my limited but nonzero
amount of testing.
Any additional testing or eyeballs on the code would be appreciated.
I'll post it for real in a day or two if it all looks OK.
> On Nov 20, 2025, at 7:39 PM, Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 11/20/25 11:27, Dave Hansen wrote:
>> On 11/20/25 11:13, Sohil Mehta wrote:
>>> The early loading probably gets affected because intel_get_platform_id()
>>> relies on boot_cpu_data which isn't initialized when load_ucode_bsp() is
>>> called very early.
>> Good point, and thanks for finding those bugs!
>>
>> We can probably just move back to building the vfm value from CPUID
>> directly as opposed to reading it from boot_cpu_data.
>
> OK, here's a theoretically fixed up series. I actually booted this on
> real hardware and made sure I didn't break microcode loading in general:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_daveh_devel.git_log_-3Fh-3Dold-2Ducode-2Dplatform&d=DwICaQ&c=s883GpUCOChKOHiocYtGcg&r=NGPRGGo37mQiSXgHKm5rCQ&m=Aj3XdJqTpjECR_fyNML3SeMNT46oTwjdjYY5YqPSZ0k2Er9zbK7KbRrCX3jepXXq&s=XwRvvtN9Ch3mUF4-T-_lRIJBcpDpHgt5ebg5Hgl8ylg&e=
> The actual hardware I tested on was this one:
>
> { .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7a, .steppings = 0x0002, .platform_mask = 0x01, .driver_data = 0x42 },
>
> For testing, I added a 100% made up but matching CPU
> model/family/stepping that has (made up) later microcode and a
> (made up) higher platform ID that I added to the ucode-defs.h file:
>
> { .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6, .model = 0x7a, .steppings = 0x0002, .platform_mask = 0x02, .driver_data = 0x43 },
>
> Everything seemed to work OK for me in my limited but nonzero
> amount of testing.
>
> Any additional testing or eyeballs on the code would be appreciated.
> I'll post it for real in a day or two if it all looks OK.
Looks like it works, no longer complains of old microcode, loading works
Tested with 6.18 rc6 + our internal patch queue + your latest patches
Before, it was broken as reported before. After, works good.
[ 2.451421] smpboot: CPU0: Intel(R) Xeon(R) Gold 5416S (family: 0x6, model: 0x8f, stepping: 0x8)
[ 3.503508] microcode: Current revision: 0x2b000643
[ 3.503510] microcode: Updated early from: 0x2b000620
tested-by/reported-by Jon Kohler <jon@nutanix.com <mailto:jon@nutanix.com>>
Thanks for tackling this!
Cheers,
Jon
On 11/20/2025 4:39 PM, Dave Hansen wrote: > Any additional testing or eyeballs on the code would be appreciated. I tried out the updated patches on an SPR system. With some made up entries the old_microcode flagging worked as expected.
© 2016 - 2026 Red Hat, Inc.