This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Problem with ACPI recognzing CPUs

To: Xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Problem with ACPI recognzing CPUs
From: beth kon <eak@xxxxxxxxxx>
Date: Tue, 07 Aug 2007 13:54:14 -0400
Delivery-date: Tue, 07 Aug 2007 10:53:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM
Reply-to: eak@xxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501)
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 

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

<Prev in Thread] Current Thread [Next in Thread>