Re: [Xen-devel] [PATCH 5/8] x86: bring up all CPUs even if not all are supposed to be used

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.07.18 at 17:38, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 11/07/18 13:09, Jan Beulich wrote:
>> Reportedly Intel CPUs which can't broadcast #MC to all targeted
>> cores/threads because some have CR4.MCE clear will shut down. Therefore
>> we want to keep CR4.MCE enabled when offlining a CPU, and we need to
>> bring up all CPUs in order to be able to set CR4.MCE in the first place.
>>
>> The use of clear_in_cr4() in cpu_mcheck_disable() was ill advised
>> anyway, and to avoid future similar mistakes I'm removing clear_in_cr4()
>> altogether right here.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Instead of fully bringing up CPUs and then calling cpu_down(), another
>> option would be to suppress/cancel full bringup in smp_callin().
> 
> What is the practical difference?  When we know ahead of time that we
> are intending to part the core, then cancelling in smp_callin() seems
> cleaner.

There are things that get left out in that case, in particular anything
done in CPU_STARTING and CPU_ONLINE notifications. A prime
omission here would be mwait_idle_cpu_init() setting up C-state
information for the CPU.

The other risk I see is that of the apparent error that this causes
to be handed up the call tree. As you can see from the cpupool fix
that was necessary, we'd chance to run into more buggy error
handling paths.

All in all - originally I had also thought that this approach might be
cleaner, but the above together with the ease of invoking
cpu_down() (requiring pretty little change overall) made me
change minds. The main downside is really that runtime soft-
online attempts will make (in patch 6, as mentioned there) the
hyperthreads visible to the scheduler for a brief moment.

Jan



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