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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home