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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 29/2/08 21:46, "Chris Lalancette" <clalance@xxxxxxxxxx> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel