[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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 
cores).

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
AMD



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.