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: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] dom0 and apicid not equal to cpuid
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 12 Feb 2008 10:29:29 +0000
Delivery-date: Tue, 12 Feb 2008 02:30:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <6453C3CB8E2B3646B0D020C112613273093777@xxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Achqll4p+tddFVOYTAK5v3h066MrkQAAfHYmAJlI5yAAGSyR0w==
Thread-topic: [Xen-devel] dom0 and apicid not equal to cpuid
User-agent: Microsoft-Entourage/
On 11/2/08 22:38, "Langsdorf, Mark" <mark.langsdorf@xxxxxxx> wrote:

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

The code in processor_core.c ultimately wants to convert acpiid to cpuid. I
think we're going to be in a confusing mess if we set up the
acpiid-apicid-cpuid relationships for anything other than a dom0_vcpu_pin'ed
system. So perhaps we should expose that configuration option to dom0 (so it
can tell whether it is pinned or not). If so, it can set up its mapping
arrays just like a native kernel (we can reinstate the code for this
purpose, and backport any fixes to it as necessary). In the non-pinned case
perhaps we should initialise all those arrays to -1 for sanity's sake.

The reason I think this is a rathole for the non-pinned case is that the
cpuid space of a non-pinned dom0 kernel has no consistent relationship with
underlying physical CPUs. So when the kernel decides to make use of that
cpu-apicid-acpiid relationship information, e.g., to change power states, it
will all go horribly wrong. Setting the mapping arrays to -1 is a way to try
and nobble the ACPI code paths in a reasonably well-defined manner.

Do you think you could do the Linux side of this in a reasonably clean
manner? You could provide a Linux kernel command-line option to specify
pinned/not-pinned for now if you like, and I would do the proper plumbing
through from Xen.

 -- Keir

Xen-devel mailing list