Re: [Xen-devel] [PATCH v2 for 4.13] x86/microcode: refuse to load the same revision ucode

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.11.2019 03:22, Chao Gao wrote:
> On Fri, Nov 22, 2019 at 04:47:23PM +0000, Sergey Dyasli wrote:
>> Currently if a user tries to live-load the same or older ucode revision
>> than CPU already has, he will get a single message in Xen log like:
>>
>>    (XEN) 128 cores are to update their microcode
>>
>> No actual ucode loading will happen and this situation can be quite
>> confusing. Fix this by starting ucode update only when the provided
>> ucode revision is higher than the currently cached one (if any).
>> This is based on the property that if microcode_cache exists, all CPUs
>> in the system should have at least that ucode revision.
>>
>> Additionally, print a user friendly message if no newer ucode can be
>> found in the provided blob. This also requires ignoring -ENODATA in
>> AMD-side code, otherwise the message given to the user is:
>>
>>    (XEN) Parsing microcode blob error -61
>>
>> Which actually means that a ucode blob was parsed fine, but no matching
>> ucode was found.
>>
>> Signed-off-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
> 
> Reviewed-by: Chao Gao <chao.gao@xxxxxxxxx>
> 
> I wonder whether it is better to put the comparison ...
> 
>> @@ -641,6 +647,8 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) 
>> buf, unsigned long len)
>>     if ( !patch )
>>     {
>>         ret = -ENOENT;
>> +        printk(XENLOG_WARNING "microcode: couldn't find any newer revision 
>> in "
>> +                              "the provided blob!\n");
>>         goto put;
>>     }
> 
> ... after this if(). Then you needn't modify any vendor-specific code.

Yeah, this would seem to allow reducing code churn by quite a bit.

Also I think the AMD side -ENODATA ignoring would better go into
this

    if ( error )
    {
        xfree(mc_amd->equiv_cpu_table);
        xfree(mc_amd);
        goto out;
    }

block in cpu_request_microcode(), thus allowing potential future
unrelated -EONDATA to not also get ignored.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel