[PATCH] limit ACPIID to APICID reset to AMD machines

[PATCH] limit ACPIID to APICID reset to AMD machines

[Mark Langsdorf]

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.

-Mark Langsdorf
Operating System Research Center
AMD

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

diff -r 49ffe9ef67d4 drivers/xen/core/smpboot.c
--- a/drivers/xen/core/smpboot.c	Fri Feb 29 10:29:13 2008 +0000
+++ b/drivers/xen/core/smpboot.c	Fri Feb 29 12:54:47 2008 -0600
@@ -276,7 +276,8 @@ void __init smp_prepare_cpus(unsigned in
 
 	cpu_2_logical_apicid[0] = 0;
 	x86_cpu_to_apicid[0] = 0;
-	set_x86_acpiid_to_apicid(0, 0);
+	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+		set_x86_acpiid_to_apicid(0, 0);
 
 	current_thread_info()->cpu = 0;
 
@@ -325,7 +326,8 @@ void __init smp_prepare_cpus(unsigned in
 
 		cpu_2_logical_apicid[cpu] = cpu;
 		x86_cpu_to_apicid[cpu] = cpu;
-		set_x86_acpiid_to_apicid(cpu, cpu);
+		if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+			set_x86_acpiid_to_apicid(cpu, cpu);
 
 		idle = fork_idle(cpu);
 		if (IS_ERR(idle))

Re: [PATCH] limit ACPIID to APICID reset to AMD machines

[Chris Lalancette]

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

Re: [PATCH] limit ACPIID to APICID reset to AMD machines

[Keir Fraser]

On 29/2/08 21:46, "Chris Lalancette" <clalance@redhat.com> wrote:

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

Yes, this is the approach I originally proposed. You are quite correct that
there is no reason to suppose that ACPI IDs will map 1:1 to Xen's concept of
CPU IDs. I will yank the acpiid-apicid patch.

It shouldn't be dependent on dom0-cpufreq by the way, but merely on
dom0-vcpus-pinned.

 -- Keir