We are seeing an issue with dom0 ACPI recognizing all CPUs in the
system. This is being seen on x86_64, xen-3.1-testing, on an IBM x3950.
The machine is 128-way and I'd expect dom0 to see 32 CPUs. /proc/cpuinfo
does show 32 CPUs, but /proc/acpi/processor does not, and dom0 dmesg
shows error messages like:
ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is
not present [20060707]
ACPI: Getting cpuindex for acpiid 0x10
I have traced the problem to the following:
acpi_processor_start leads to a call to convert_acpiid_to_cpu, which
translates from acpiid to cpu using 2 tables:
1) arch_acpiid_to_apicid[acpi_id] - translates from acpiid to apic_id.
This table is initialized via the ACPI MADT table. apic_ids on this box
range from 0 to 247;
2) arch_cpu_to_apicid - translates from apic_id found above to cpu. This
table is initialized in drivers/xen/core/smpboot.c:
void __init smp_prepare_cpus(unsigned int max_cpus)
{
...
x86_cpu_to_apicid[cpu] = cpu;
...
}
The contents of this table increase linearly, in this case from 0 to 31.
So, when apic_ids are above 31, as found in the MADT, they can not be found in the
x86_cpu_to_apicid table by convert_acpiid_to_cpu, leading to the processor being
"NOT_FOUND" by ACPI.
Can anyone explain why xen/core/smpboot.c linearly correlates cpu to apic_id, causing problems for machines that have large apic_ids? I'm not sure what the right solution to this problem is.
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak@xxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel