[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38660F8F-499E-48CD-B58B-4822228A5941@nutanix.com>
Date: Wed, 22 Oct 2025 17:14:58 +0000
From: Jon Kohler <jon@...anix.com>
To: Sohil Mehta <sohil.mehta@...el.com>
CC: Dave Hansen <dave.hansen@...ux.intel.com>,
"x86@...nel.org"
<x86@...nel.org>, Borislav Petkov <bp@...en8.de>,
Thomas Gleixner
<tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
"H . Peter Anvin"
<hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf
<jpoimboe@...nel.org>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Dave
Hansen <dave.hansen@...el.com>,
Nikolay Borisov <nik.borisov@...e.com>,
Alex
Murray <alex.murray@...onical.com>,
Andrew Cooper
<andrew.cooper3@...rix.com>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
"stable@...nel.org" <stable@...nel.org>
Subject: Old microcode CPU matching issue - x86/microcode/intel: Refresh the
revisions that determine old_microcode
> On Aug 18, 2025, at 3:01 PM, Sohil Mehta <sohil.mehta@...el.com> wrote:
>
> Update the minimum expected revisions of Intel microcode based on the
> microcode-20250512 (May 2025) release.
>
> Cc: <stable@...nel.org> # v6.15+
> Signed-off-by: Sohil Mehta <sohil.mehta@...el.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
Powered by blists - more mailing lists