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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/09/2026 10:35 am, Roger Pau Monné wrote:
> On Tue, Sep 08, 2026 at 06:15:25PM +0100, Andrew Cooper wrote:
>> +
>> +    /*
>> +     * Treat pre-production as always safe - anyone using pre-production
>> +     * microcode knows what they are doing, and can keep any resulting 
>> pieces.
>> +     */
>> +    if ( (int)cpu_sig->rev < 0 || mc->rev < 0 )
>> +        return true;
>> +
>> +    /*
>> +     * GNR98 states that Granite Rapids systems hang when loading new ucode 
>> on
>> +     * sufficiently old firmware.  GNR101 retroactively states that one 
>> ucode
>> +     * had an incorrect minimum revision field, in light of discovering 
>> GNR98.
>> +     *
>> +     * Both are incomplete statements of the problem.
>> +     *
>> +     * At the time of writing (August 2026), the believed safe sequence is:
>> +     *   0x01000370 -> [0x01000380...0x010003f3] -> 0x01000405 -> any later
>> +     *
>> +     * Disallow known-unsafe loads while permitting believed-safe loads.  
>> For
>> +     * GNR, this allows multi-hop loading to get up to the latest.
>> +     */
>> +    if ( boot_cpu_data.vfm == INTEL_GRANITERAPIDS_X &&
>> +         boot_cpu_data.stepping == 1 && (cpu_sig->pf & 0x95) &&
>> +         ((cpu_sig->rev < 0x01000380 && mc->rev >= 0x01000405) ||
>> +          (cpu_sig->rev < 0x01000405 && mc->rev >  0x01000405)) )
> Given the logic, I don't think the CPU needs to strictly be in version
> 0x01000370 to update to the [0x01000380...0x010003f3] range?
>
> Maybe you want to replace 0x01000370 with "any previous" to match the
> semantics used in the tail of the sequence with "any later".

Hmm.  370 was the first release, so the analysis of the problem stops
there.  Everything older was development phase.

But yes, the eventual planned fix doesn't have 370 as a boundary, so
I'll adjust to "previous".

>
> In any case:
>
> Reviewed-by: Roger Pau Monné <roger@xxxxxxxxxxxxxx>

Thanks.

~Andrew