[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 11/12] x86/microcode: Synchronize late microcode loading



>>> On 13.03.19 at 08:54, <JBeulich@xxxxxxxx> wrote:
>>>> On 13.03.19 at 06:02, <chao.gao@xxxxxxxxx> wrote:
>> On Tue, Mar 12, 2019 at 05:07:51PM -0700, Raj, Ashok wrote:
>>>On Mon, Mar 11, 2019 at 03:57:35PM +0800, Chao Gao wrote:
>>>> +    if ( cpu == cpumask_first(per_cpu(cpu_sibling_mask, cpu)) )
>>>> +        ret = microcode_update_cpu();
>>>
>>>Does ret have any useful things on if the update failed? Doesn't seem 
>>>to be used before you overwrite later in collect_cpu_info()?
>> 
>> It has the reason of failure on error. Actally, there are two reasons:
>> one is no patch of newer revision, the other is we tried to update but
>> the microcode revision didn't change. I can check this return value and
>> print more informative message to admin. And furthermore, for the
>> latter, we can remove the ucode patch from caches to address Roger's
>> concern expressed in comments to patch 4 & 5.
> 
> Btw, I'm not sure removing such ucode from the cache is appropriate:
> It may well apply elsewhere, unless there's a clear indication that the
> blob is broken. So perhaps there needs to be special casing of -EIO,
> which gets returned when the ucode rev reported by the CPU after
> the update does not match expectations.

An to go one step further, perhaps we should also store more than
just the newest variant for a given pf. If the newest fails to apply
but there is another one newer than what's on a CPU, updating to
that may work, and once that intermediate update worked, the
update to the newest version may then work too.

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.