Problem with ACPI recognzing CPUs

Problem with ACPI recognzing CPUs

[beth kon]

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

Re: Problem with ACPI recognzing CPUs

[Keir Fraser]

On 7/8/07 18:54, "beth kon" <eak@us.ibm.com> wrote:

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

I'm not sure there's a better solution than not building/initialising
arch/acpi/processor_core.c on Xen. The processor-specific ACPI code isn't
going to run well on Xen where dom0 VCPUs may migrate around and not even
see all physical CPUs. The warnings you see are scary looking but harmless.

I suspect we've never noticed these before because we build the acpi
processor code as a module that we never load.

 -- Keir