[PATCH 0/2] x86/intel: Refresh the old ucode revisions with a script

[PATCH 0/2] x86/intel: Refresh the old ucode revisions with a script

[Sohil Mehta]

The kernel maintains a list of recently released Intel microcode
revisions for each family-model-stepping. Systems with microcode older
than those listed are marked with X86_BUG_OLD_MICROCODE [1].

Naturally, the microcode list needs to be periodically updated to
reflect the latest releases. This series introduces a script to simplify
this process along with the first update.

Microcode revision update (Patch 1)
-----------------------------------
The update is based on the May 2025 Intel microcode release [2]. Even if
this is taken through the x86/urgent branch, a gap of 3 months seems
like enough time for systems to have been updated. If there are concerns
regarding the timing, the patch can be taken through the regular merge
window.

It also includes a stable Cc to keep the stable trees up-to-date.

The update script (Patch 2)
---------------------------
Below is the help text for the script. Any feedback on the interface or
the help text is appreciated.

$ ./scripts/update-intel-ucode-defs.py -h
usage: update-intel-ucode-defs.py [-h] -u UCODE_PATH [-o HEADER]

For Intel CPUs, update the microcode revisions that determine
X86_BUG_OLD_MICROCODE.

The script takes the Intel microcode files as input and uses the
iucode-tool to extract the revision information. It formats the output
and writes it to intel-ucode-defs.h which holds the minimum expected
revision for each family-model-stepping.

A typical usage is to get the desired release of the Intel Microcode
Update Package at:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.git

And run:
    ./scripts/update-intel-ucode-defs.py -u /path/to/microcode/files

Note: The microcode revisions are usually updated shortly after a new
microcode package is released, allowing a reasonable time for systems to
get the update.

options:
  -h, --help            show this help message and exit
  -u UCODE_PATH, --ucode_path UCODE_PATH
                        Path to the microcode files
  -o HEADER, --output HEADER
                        The microcode header file to be updated (default: intel-ucode-defs.h)

Links
-----
[1]: https://lore.kernel.org/lkml/174530444932.31282.15748299566756052894.tip-bot2@tip-bot2/
[2]: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20250512

Sohil Mehta (2):
  x86/microcode/intel: Refresh the revisions that determine
    old_microcode
  scripts/x86: Add a script to update minimum Intel ucode revisions

 MAINTAINERS                                   |   1 +
 .../kernel/cpu/microcode/intel-ucode-defs.h   |  86 ++++++-----
 scripts/update-intel-ucode-defs.py            | 134 ++++++++++++++++++
 3 files changed, 183 insertions(+), 38 deletions(-)
 create mode 100755 scripts/update-intel-ucode-defs.py

-- 
2.43.0

[PATCH 1/2] x86/microcode/intel: Refresh the revisions that determine old_microcode

[Sohil Mehta]

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.0

Re: [PATCH 1/2] x86/microcode/intel: Refresh the revisions that determine old_microcode

[Pawan Gupta]

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.

> -{ .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 @@

Re: [PATCH 1/2] x86/microcode/intel: Refresh the revisions that determine old_microcode

[Andrew Cooper]

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

Re: [PATCH 1/2] x86/microcode/intel: Refresh the revisions that determine old_microcode

[Sohil Mehta]

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

Re: [PATCH 1/2] x86/microcode/intel: Refresh the revisions that determine old_microcode

[Pawan Gupta]

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.

Re: [PATCH 1/2] x86/microcode/intel: Refresh the revisions that determine old_microcode

[Pawan Gupta]

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.

Re: [PATCH 1/2] x86/microcode/intel: Refresh the revisions that determine old_microcode

[Dave Hansen]

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.

Re: [PATCH 1/2] x86/microcode/intel: Refresh the revisions that determine old_microcode

[Andrew Cooper]

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

Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old_microcode

[Jon Kohler]

> 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

Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old_microcode

[Dave Hansen]

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.

Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old_microcode

[Dave Hansen]

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.

Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old_microcode

[Jon Kohler]

> 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

Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old_microcode

[Sohil Mehta]

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

Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old_microcode

[Sohil Mehta]

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)

Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old_microcode

[Dave Hansen]

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.

Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old_microcode

[Dave Hansen]

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.

Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old_microcode

[Sohil Mehta]

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.

Re: Old microcode CPU matching issue - x86/microcode/intel: Refresh the revisions that determine old_microcode

[Jon Kohler]

> 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

[PATCH 2/2] scripts/x86: Add a script to update minimum Intel ucode revisions

[Sohil Mehta]

The kernel keeps a table of the minimum expected microcode revisions for
Intel CPUs at intel-ucode-defs.h. Systems with microcode older those are
marked with X86_BUG_OLD_MICROCODE. For more details, see
Documentation/admin-guide/hw-vuln/old_microcode.rst.

Add a simple script to keep the header file up-to-date based on released
microcode updates.

Originally-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
 MAINTAINERS                        |   1 +
 scripts/update-intel-ucode-defs.py | 134 +++++++++++++++++++++++++++++
 2 files changed, 135 insertions(+)
 create mode 100755 scripts/update-intel-ucode-defs.py

diff --git a/MAINTAINERS b/MAINTAINERS
index daf520a13bdf..a819559ec672 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27260,6 +27260,7 @@ S:	Maintained
 F:	Documentation/admin-guide/hw-vuln/
 F:	arch/x86/include/asm/nospec-branch.h
 F:	arch/x86/kernel/cpu/bugs.c
+F:	scripts/update-intel-ucode-defs.py
 
 X86 MCE INFRASTRUCTURE
 M:	Tony Luck <tony.luck@intel.com>
diff --git a/scripts/update-intel-ucode-defs.py b/scripts/update-intel-ucode-defs.py
new file mode 100755
index 000000000000..b8248f023cce
--- /dev/null
+++ b/scripts/update-intel-ucode-defs.py
@@ -0,0 +1,134 @@
+#!/usr/bin/python3
+# SPDX-License-Identifier: GPL-2.0
+import argparse
+import re
+import shutil
+import subprocess
+import sys
+import os
+
+script = os.path.relpath(__file__)
+
+DESCRIPTION = f"""
+For Intel CPUs, update the microcode revisions that determine
+X86_BUG_OLD_MICROCODE.
+
+The script takes the Intel microcode files as input and uses the
+iucode-tool to extract the revision information. It formats the output
+and writes it to intel-ucode-defs.h which holds the minimum expected
+revision for each family-model-stepping.
+
+A typical usage is to get the desired release of the Intel Microcode
+Update Package at:
+https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.git
+
+And run:
+    ./{script} -u /path/to/microcode/files
+
+Note: The microcode revisions are usually updated shortly after a new
+microcode package is released, allowing a reasonable time for systems to
+get the update.
+"""
+
+# Get the path to the microcode header defines
+script_path = os.path.abspath(sys.argv[0])
+linux_root = os.path.dirname(os.path.dirname(script_path))
+ucode_hdr = os.path.join(linux_root, 'arch/x86/kernel/cpu/microcode/intel-ucode-defs.h')
+
+parser = argparse.ArgumentParser(description=DESCRIPTION,
+                                 formatter_class=argparse.RawDescriptionHelpFormatter)
+parser.add_argument('-u','--ucode_path', required=True,
+                    help='Path to the microcode files')
+parser.add_argument('-o','--output', dest='header', default=ucode_hdr,
+                    help='The microcode header file to be updated (default: intel-ucode-defs.h)')
+
+args = parser.parse_args()
+
+# Process the microcode files using iucode-tool
+if shutil.which("iucode-tool") is None:
+    print("Error: iucode-tool not found, please install it")
+    sys.exit(1)
+
+cmd = ['iucode-tool', '--list-all' ]
+cmd.append(args.ucode_path)
+
+process = subprocess.Popen(cmd, stdout=subprocess.PIPE, universal_newlines=True)
+process.wait()
+if process.returncode != 0:
+    print("Error: iucode-tool ran into an error, exiting")
+    sys.exit(1)
+
+# Functions to extract family, model, and stepping
+def bits(val, bottom, top):
+    mask = (1 << (top + 1 - bottom)) - 1
+    mask = mask << bottom
+    return (val & mask) >> bottom
+
+def family(sig):
+    if bits(sig, 8, 11) == 0xf:
+        return bits(sig, 8, 11) + bits(sig, 20, 27)
+    return bits(sig, 8, 11)
+
+def model(sig):
+    return bits(sig, 4, 7)  | (bits(sig, 16, 19) << 4)
+
+def step(sig):
+    return bits(sig, 0, 3)
+
+# Parse the output of iucode-tool
+siglist = []
+for line in process.stdout:
+    if line.find(" sig ") == -1:
+        continue
+    sig = re.search('sig (0x[0-9a-fA-F]+)', line).group(1)
+    rev = re.search('rev (0x[0-9a-fA-F]+)', line).group(1)
+    sig = int(sig, 16)
+    rev = int(rev, 16)
+    debug_rev = bits(rev, 31, 31)
+    if debug_rev != 0:
+        print("Error: Debug ucode file found, exiting")
+        sys.exit(1);
+
+    sigrev = {}
+    sigrev['sig'] = sig
+    sigrev['rev'] = rev
+    siglist = siglist + [ sigrev ]
+
+# Remove duplicates, if any
+sigdict = {}
+for sr in siglist:
+    existing = sigdict.get(sr['sig'])
+    if existing != None:
+        # If the existing one is newer, just move on:
+        if existing['rev'] > sr['rev']:
+            continue
+    sigdict[sr['sig']] = sr
+
+# Prepare and sort the microcode entries
+ucode_entries = []
+for sig in sigdict:
+    rev = sigdict[sig]
+    ucode_entries.append({
+        'family': family(sig),
+        'model': model(sig),
+        'steppings': 1 << step(sig),
+        'rev': rev['rev'],
+        'sig': sig
+    })
+
+if not ucode_entries:
+    print("Error: No valid microcode files found, exiting")
+    sys.exit(1)
+
+ucode_entries.sort(key=lambda x: (x['family'], x['model'], x['steppings']))
+
+# Update the microcode header file
+header_path = args.header
+if not os.path.exists(header_path):
+    print(f"Error: '{header_path}' does not exist, use the '-o' option to specify a file to update")
+    sys.exit(1)
+
+with open(header_path, "w") as f:
+    for entry in ucode_entries:
+        f.write("{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x%x,  .model = 0x%02x, .steppings = 0x%04x, .driver_data = 0x%x },\n" %
+                (entry['family'], entry['model'], entry['steppings'], entry['rev']))
-- 
2.43.0

Re: [PATCH 2/2] scripts/x86: Add a script to update minimum Intel ucode revisions

[Dave Hansen]

On 8/18/25 12:01, Sohil Mehta wrote:
> +parser.add_argument('-u','--ucode_path', required=True,
> +                    help='Path to the microcode files')
> +parser.add_argument('-o','--output', dest='header', default=ucode_hdr,
> +                    help='The microcode header file to be updated (default: intel-ucode-defs.h)')

So, thanks for fixing this up and adding the sorting.

But I'm not sure what the point is of making it less flexible and adding
these command-line arguments to it. Before, I would just hand it a path
to a bunch of ucode files, and dump the output somewhere:

	foo.py ~/path/* > out.h

I just went and tried to use my version of the script to dump headers
for every microcode release:

	git rev-list --all | while read rev; do
		git checkout $rev;
		python3 dave.py ~/path/* > foo.${rev}.h
	done

But with your version, I can't do that. I have to create the header
file, then point the script to it. I also have to consume microcode
files from a single directory.

So, it's less flexible and harder to use with those command-line
arguments. It's obviously not the end of the world, but why add code to
the script for this? Why is it needed?

Re: [PATCH 2/2] scripts/x86: Add a script to update minimum Intel ucode revisions

[Sohil Mehta]

On 8/19/2025 10:14 AM, Dave Hansen wrote:

> But with your version, I can't do that. I have to create the header
> file, then point the script to it. I also have to consume microcode
> files from a single directory.
> 

Consuming microcode from multiple directories is easy to fix, just need
to add "nargs='+'" in the argument parser. Will change in the next
revision.


> So, it's less flexible and harder to use with those command-line
> arguments. It's obviously not the end of the world, but why add code to
> the script for this? Why is it needed?

Though the script is less flexible, my goal was to make it easier to
use. When used within the kernel tree, it automatically selects and
updates the header file, since that is always the same.

The usage was supposed to be simple and hard to mess up:

	update.py -u /path/to/microcode/files

The header argument is only needed if someone uses the script outside
the tree, which I assumed to be rare. But I understand this limits other
usages.

To make it flexible again, I can get rid of the parameters and make it
print to standard output. Users would then redirect it as needed.

	update.py /path/to/files1 /path/to/files2 > /path/to/ucode-def.h