From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Lalancette Subject: Re: [PATCH] limit ACPIID to APICID reset to AMD machines Date: Fri, 29 Feb 2008 16:46:58 -0500 Message-ID: <47C87D52.9030000@redhat.com> References: <200802291302.32010.mark.langsdorf@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200802291302.32010.mark.langsdorf@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Mark Langsdorf Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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