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

Re: [Xen-devel] [PATCH v1 2/2] microcode: reject late ucode loading if any core is parked



On 21.11.2019 12:51, Chao Gao wrote:
> On Thu, Nov 21, 2019 at 11:21:13AM +0100, Jan Beulich wrote:
>> On 21.11.2019 00:05, Chao Gao wrote:
>>> If a core with all of its thread being parked, late ucode loading
>>> which currently only loads ucode on online threads would lead to
>>> differing ucode revisions in the system. In general, keeping ucode
>>> revision consistent would be less error-prone. To this end, if there
>>> is a parked thread doesn't have an online sibling thread, late ucode
>>> loading is rejected.
>>
>> I'm confused. I thought we had agreed that the long term solution
>> would be to briefly bring online a thread of cores with all their
>> threads parked.
> 
> I don't remeber that we reached such an aggrement. But if it happened,
> I am really sorry for forgeting it.
> 
> Actually, I think Dom0 has the information (cpu topology and each cpu's
> offline/online status) to decide if there is a parked core or not.
> IMO, rejecting late loading in this case is just a defense check. Dom0
> is able to correct the situation by bringing up some cpus.

Dom0 can _fully_ bring up CPUs, but not with the intent of _just_
getting their ucode updated.

>> What you do here was meant to be a temporary step
>> only for 4.13, for which it is too late now (unless Jürgen
>> indicates otherwise).
>>
>>> --- a/xen/arch/x86/microcode.c
>>> +++ b/xen/arch/x86/microcode.c
>>> @@ -584,6 +584,51 @@ static int do_microcode_update(void *patch)
>>>      return ret;
>>>  }
>>>  
>>> +static unsigned int unique_core_id(unsigned int cpu, unsigned int 
>>> socket_shift)
>>> +{
>>> +    unsigned int core_id = cpu_to_cu(cpu);
>>> +
>>> +    if ( core_id == INVALID_CUID )
>>> +        core_id = cpu_to_core(cpu);
>>> +
>>> +    return (cpu_to_socket(cpu) << socket_shift) + core_id;
>>> +}
>>> +
>>> +static int has_parked_core(void)
>>> +{
>>> +    int ret;
>>> +    unsigned int cpu, max_bits, core_width;
>>> +    unsigned int max_sockets = 1, max_cores = 1;
>>> +    unsigned long *bitmap;
>>> +
>>> +    if ( !park_offline_cpus )
>>> +        return 0;
>>> +
>>> +    for_each_parked_cpu(cpu)
>>> +    {
>>> +        /* Note that cpu_to_socket() get an ID starting from 0. */
>>> +        max_sockets = max(max_sockets, cpu_to_socket(cpu) + 1);
>>> +        max_cores = max(max_cores, cpu_data[cpu].x86_max_cores);
>>> +    }
>>> +
>>> +    core_width = fls(max_cores);
>>> +    max_bits = max_sockets << core_width;
>>
>> Isn't this off by one? If max_cores is 1, you don't need to shift
>> max_sockets (or the cpu_to_socket() value in unique_core_id()) at
>> all, for example.
>>
>> With this in mind, instead of the park_offline_cpus check at the
>> top of the function, wouldn't it make sense to check here whether
>> max_sockets and max_cores are both still 1, in which case at
>> least one thread of the only core of the only socket in the system
>> is obviously still online (the one we're running on)?
> 
> Agree. Will follow your suggestion.

Aiui it'll be correct again only if the parked map gets allocated
unconditionally.

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®.