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] [PATCH] limit ACPIID to APICID reset to AMD machines

To: Mark Langsdorf <mark.langsdorf@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] limit ACPIID to APICID reset to AMD machines
From: Chris Lalancette <clalance@xxxxxxxxxx>
Date: Fri, 29 Feb 2008 16:46:58 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 29 Feb 2008 13:47:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200802291302.32010.mark.langsdorf@xxxxxxx>
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: <200802291302.32010.mark.langsdorf@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20071115)
Mark Langsdorf wrote:
> Testing by Red Hat show that changeset:0034d9389130 causes regressions
> on Intel machines that don't use APIC ID lifting but that do have a
> strange ACPI to APIC numbering.
> Modify the patch so that it only applies to AMD machines.

This is still not right, because I saw the odd behavior on AMD machines
from a certain vendor.

>From my understanding though, this is addressing the wrong problem.  The
real issue with the 16 core AMD's is that the APICID != CPUID, which it
seems to on all other platforms I've looked at.  So the real problem is
not the acpiid_to_apicid array, but rather the cpu_to_apicid array.  So
in the default case (cpufreq off, dom0 vcpu unpinned), we want the
current code, while with cpufrequency (cpufreq on, dom0 vcpu pinned) we
want to stick with the tables we parse out of ACPI.  It seems to me the
correct fix here would be to actually parse the tables in mpparse-xen.c,
and then do something like:

if (!hypervisor_cpufreq_enabled())
     x86_cpu_to_apicid(cpu, cpu)

in smpboot.c  (and then drop everything mucking with the
acpiid_to_apicid array).  The question, of course, becomes how to
determine that cpufreq is enabled or not.  Is there a dom0 platform op
that we could query to find this out, and if not, can we add one?

Chris Lalancette

Xen-devel mailing list

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