Re: [PATCH] x86/ucode: Work around Granite Rapids erraturm GNR98

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.09.2026 09:51, Andrew Cooper wrote:
> 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.

Can this difference to the erratum text then please be mentioned in
the description (or even a code comment)?

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

We've done nothing, literally. That leaves the system in potentially
problematic state (newer ucode available, which likely addresses known
issues).

Jan