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


RE: [Xen-devel] dom0 and apicid not equal to cpuid

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] dom0 and apicid not equal to cpuid
From: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>
Date: Mon, 11 Feb 2008 16:38:18 -0600
Delivery-date: Mon, 11 Feb 2008 14:38:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3D277EB.13857%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <6453C3CB8E2B3646B0D020C112613273093767@xxxxxxxxxxxxxxxxx> <C3D277EB.13857%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Achqll4p+tddFVOYTAK5v3h066MrkQAAfHYmAJlI5yA=
Thread-topic: [Xen-devel] dom0 and apicid not equal to cpuid

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
> Sent: Friday, February 08, 2008 3:20 PM
> To: Langsdorf, Mark; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] dom0 and apicid not equal to cpuid
> On 8/2/08 21:05, "Langsdorf, Mark" <mark.langsdorf@xxxxxxx> wrote:
> > Some AMD processor systems assign the boot processor
> > (cpu 0) to apicid 4.  Standard Linux handles this
> > cleanly by keeping track of the correspondences amongst
> > cpu id, apic id, and acpi id.  dom0 Xen does not have
> > the code to do that, and AMD is seeing some strange
> > behavior on our 4 socket quad-core systems.
> > 
> > Specifically, when we try to get ACPI information for
> > cpu 0, the correspondences break down and the request
> > fails.
> > 
> > I know some of the code needs to be added to mpparse-xen.c,
> > but it looks like the relevant code was #ifdef'd out in
> > the first place.  Does anyone know why the code to match
> > cpuids to apicids was removed and what would need to be
> > done to restore it?
> Can you point out the specific troubling code in our Linux 
> tree (e.g., the specific #if0'ed code, and also the place
> where the kernel ultimately gets confused and the request fails)?

Sure.  in arch/x86_64/kernel/mpparse-xen.c,
there is no code in mp_register_lapic_address(), so dom0 has no
idea who the boot CPU is.  Later, when mp_register_lapic() is
called, it still doesn't have this information, so it can't
pass this information to MP_processor_info().  MP_processor_info()
doesn't get the cpuid to apicid information from the previous
functions, so it sets the cpu_to_apicidp[] table using some other 
method such that apicid is assumed to be cpuid.  However, acpiid 
is not the same as apicid, so later when drivers/acpi/processor_core.c
tries to recover _PSS objects, it can't always get the _PSS
objects because it starts searching at cpu id 4 (instead of 0)
and fails when looking for cpu id 16+ (on a system with 16 

It appears that the call to GET_APIC_ID() in 
mp_register_lapic_address() isn't legal for dom0, but the failure
to make that call results in an incorrect cpu_to_apicid[] table
and that means the acpiid_to_apicid[] table is also wrong.

-Mark Langsdorf
Operating System Research Center

Xen-devel mailing list