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

[Dave Hansen <dave.hansen@intel.com>]

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.