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

[Andrew Cooper <andrew.cooper3@citrix.com>]

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@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