Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.11.15 at 02:21, <eswierk@xxxxxxxxxxxxxxxxxx> 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.

But that raises the question of sanity of the CPUID output Xen gets
presented: With

> (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> (XEN) Processor #0 6:6 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled)
> (XEN) Processor #2 6:6 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled)
> (XEN) Processor #4 6:6 APIC version 21
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled)
> (XEN) Processor #6 6:6 APIC version 21

and taking the output you added, I can only suspect that the value
used for determining the socket shift is unexpected (CPUID leaf 0xb).
Could you supply the observed values? (See
detect_extended_topology() and set_nr_sockets().) As you can
see, the core IDs ("CPU: Physical Processor ID: ...") aren't sequential,
which we expect them to be (with holes left only when non-power-of-2
values need taking care of).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel