[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

[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 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 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 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

[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

[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

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