Problem with ACPI recognzing CPUs

[beth kon <eak@us.ibm.com>]

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@us.ibm.com