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 <jbeul...@suse.com>
> ---
> 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.

> --- a/xen/arch/x86/mpparse.c
> +++ b/xen/arch/x86/mpparse.c
> @@ -68,18 +68,26 @@ physid_mask_t phys_cpu_present_map;
>  
>  void __init set_nr_cpu_ids(unsigned int max_cpus)
>  {
> +     unsigned int tot_cpus = num_processors + disabled_cpus;
> +
>       if (!max_cpus)
> -             max_cpus = num_processors + disabled_cpus;
> +             max_cpus = tot_cpus;
>       if (max_cpus > NR_CPUS)
>               max_cpus = NR_CPUS;
>       else if (!max_cpus)
>               max_cpus = 1;
>       printk(XENLOG_INFO "SMP: Allowing %u CPUs (%d hotplug CPUs)\n",
>              max_cpus, max_t(int, max_cpus - num_processors, 0));
> -     nr_cpu_ids = max_cpus;
> +
> +     if (!park_offline_cpus)
> +             tot_cpus = max_cpus;
> +     nr_cpu_ids = min(tot_cpus, NR_CPUS + 0u);
> +     if (park_offline_cpus && nr_cpu_ids < num_processors)
> +             printk(XENLOG_WARNING "SMP: Cannot bring up %u further CPUs\n",
> +                    num_processors - nr_cpu_ids);
>  
>  #ifndef nr_cpumask_bits
> -     nr_cpumask_bits = (max_cpus + (BITS_PER_LONG - 1)) &
> +     nr_cpumask_bits = (nr_cpu_ids + (BITS_PER_LONG - 1)) &
>                         ~(BITS_PER_LONG - 1);

ROUNDUP() ?

~Andrew

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

Reply via email to