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>
Subject: Re: [Xen-devel] dom0 and apicid not equal to cpuid
From: "Mark Langsdorf" <mark.langsdorf@xxxxxxx>
Date: Thu, 14 Feb 2008 16:16:39 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 14 Feb 2008 14:16:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3D278A0.13859%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: <C3D278A0.13859%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6 (enterprise 20070904.708012)
On Friday 08 February 2008, Keir Fraser wrote:
> On 8/2/08 21:19, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:
> >> 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?
> > 
> > Probably most of the things that depend on it are actually managed by Xen
> > itself. Possibly this assumption is wrong and the code needs to be re-added,
> > or perhaps the problem is actually within Xen?
> > 
> > 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)?
> Also, a link to the upstream patch, or area of code in an upstream kernel,
> that you think needs to be added would be useful too.

Simpler solution that the one I proposed above: Fix the APIC to ACPI mappings
in drivers/xen/core/smpboot.c.  That doesn't require pinning vcpus or knowing
about the underlying APIC/ACPI/CPU ID interaction.  

Patch for this solution below:

Xen dom0 arbitrarily assigns APIC ID x to CPU ID x.  Make dom0 also assign
the APIC ID to ACPI ID mapping in the same way.

Signed-off-by: Mark Langsdorf <mark.langsdorf@xxxxxxx>

diff -r 08e85e79c65d drivers/xen/core/smpboot.c
--- a/drivers/xen/core/smpboot.c        Mon Feb 11 11:05:27 2008 +0000
+++ b/drivers/xen/core/smpboot.c        Thu Feb 14 16:12:41 2008 -0600
@@ -269,6 +269,7 @@ void __init smp_prepare_cpus(unsigned in
        cpu_2_logical_apicid[0] = 0;
        x86_cpu_to_apicid[0] = 0;
+       x86_acpiid_to_apicid[0] = 0;
        current_thread_info()->cpu = 0;
@@ -317,6 +318,7 @@ void __init smp_prepare_cpus(unsigned in
                cpu_2_logical_apicid[cpu] = cpu;
                x86_cpu_to_apicid[cpu] = cpu;
+               x86_acpiid_to_apicid[cpu] = cpu;
                idle = fork_idle(cpu);
                if (IS_ERR(idle))

Xen-devel mailing list