Re: Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

[Chao Peng <chao.p.peng@linux.intel.com>]

On Fri, Nov 20, 2015 at 05:21:11PM -0800, Ed Swierk wrote:
> The problem is that the index of the socket_cpumask array is derived via
> cpu_to_socket() from the APIC ID of the processor in a given socket, but
> the size of the array is computed based on nr_sockets, which is not
> necessarily equal to the maximum APIC ID.
> 
> Sizing the socket_cpumask to MAX_APICS rather than nr_sockets seems safer,
> though a bit wasteful. I verified that this change fixes the boot crash
> with 4 or 8 CPUs on VMware Fusion.
> 
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -819,7 +819,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
> 
>      set_nr_sockets();
> 
> -    socket_cpumask = xzalloc_array(cpumask_t *, nr_sockets);
> +    socket_cpumask = xzalloc_array(cpumask_t *, MAX_APICS);

Just replacing nr_sockets with MAX_APICS can not really solve problem.
socket_cpumask should always be synchronized with nr_sockets, otherwise
at least some function will be missing, if not cause panic in another 
place.

If possible, I'd suggest you can debug set_nr_sockets(), especially you
can inspect the following two values for panic case:
boot_cpu_data.x86_max_cores
boot_cpu_data.x86_num_siblings

Thanks,
Chao