On 03/09/2026 7:41 am, Jan Beulich wrote:
> On 03.09.2026 00:10, Andrew Cooper wrote:
>> @@ -273,6 +274,35 @@ static bool microcode_fits_cpu(const struct
>> microcode_patch *mc)
>> return false;
>> }
>>
>> +static bool microcode_safe_to_load(const struct microcode_patch *mc)
>> +{
>> + struct cpu_signature *cpu_sig = &this_cpu(cpu_sig);
>> +
>> + /*
>> + * Treat pre-production as always safe - anyone using pre-production
>> + * microcode knows what they are doing, and can keep any resulting
>> pieces.
>> + */
>> + if ( cpu_sig->rev < 0 || mc->rev < 0 )
>> + return true;
>> +
>> + /*
>> + * GNR98. Granite Rapids systems hang when loading new ucode on
>> + * sufficiently old firmware.
>> + */
>> + if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X &&
>> + boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) &&
>> + cpu_sig->rev < 0x01000405 &&
>> + mc->rev > 0x01000405 )
> The erratum text says "to 0x1000405 or later". Question is whether that's
> correct,
> as it would mean that it's impossible to update from earlier than 0x1000405.
> Then
> the workaround text says exactly this.
"Correct" is complicated.
The text is technically correct when considering all pre-production
microcode that Intel had during development. It is not correct for
production systems where OEMs followed instruction about which first
version to use. Specifically, 0x01000405 does load safely on the first
production-certified firmware.
Critically, >= breaks the aforementioned "more complete solution" (which
can safely load up to latest even on old firmware) where I'm still
waiting on Intel to adjust the blobs in the ucode repository.
>> + {
>> + printk_once(XENLOG_WARNING
>> + "microcode: Granite Rapids erratum GNR98 detected.
>> Skipping ucode 0x%08x\n"
>> + "microcode: Firmware update recommended\n", mc->rev);
>> + return false;
> Should we additionally taint the system?
Why? We've done nothing to make it potentially unstable/problematic.
~Andrew
