From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42782) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sogwl-0004yC-HL for qemu-devel@nongnu.org; Tue, 10 Jul 2012 16:22:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sogwg-0001tw-Iw for qemu-devel@nongnu.org; Tue, 10 Jul 2012 16:22:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sogwg-0001ta-AO for qemu-devel@nongnu.org; Tue, 10 Jul 2012 16:22:06 -0400 From: Eduardo Habkost Date: Tue, 10 Jul 2012 17:22:15 -0300 Message-Id: <1341951743-2285-1-git-send-email-ehabkost@redhat.com> Subject: [Qemu-devel] [RFC 0/7+1] QEMU APIC ID + topology bug + CPU hotplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Igor Mammedov , seabios@seabios.org, Gleb Natapov , Anthony Liguori Hi, This is more a call for discussion than a request for comments in the actual code. Our problem today is: - Lots of QEMU and Seabios code have the assumption that Initial APIC ID == CPU "index" (in other words, that APIC IDs are always contiguous and start at 0); - However, the Initial APIC IDs may be non-contiguous depending on the requested CPU topology (core/thread counts), so we have to break that assumption (see [1]). This series is how a fix could look like if we had the following assumptions: - Seabios can't run any code in hotplugged CPUs; - We don't change the current CPU hotplug interface between the Seabios SSDT code and QEMU (the interface used by method PRSC at acpi-dsdt.dsl in Seabios) Note that I am more than willing to break any of the assumptions above, and get rid of FW_CFG_LAPIC_INFO. But I don't know what's the best way to do it. For the non-hotplug CPUs, it would be quite easy: just make Seabios get the initial APIC ID from the AP processors on boot, at smp.c:smp_ap_boot_code. The hotplug case is a bit more complex: we need to either: - have a mechanism to let the ACPI SSDT code know what's the APIC ID of hotplugged CPUs; or - make Seabios run some code in the hotplugged CPU (I am assuming that this is simply not possible). I am hoping people have suggestions to solve this. I don't know where the interface used by acpi-dsdt.dsl:PRSC comes from, and if it can be easily extended or changed. All that said, I have one question: is it acceptable to apply a fix for the APIC- ID/topology bug that knowingly breaks CPU hotplug, by now? (not exactly the fix in this series, but a fix that simply makes Seabios query the APIC IDs directly from the CPUs). Note that this series is incomplete and not completely tested. Know issues: - It breaks CPU hotplug because the SSDT code in Seabios is still incorrect; - It breaks live-migration because the initial APIC ID will be different even for older machine-types (and the initial APIC ID is not part of the CPU state sent during migration); - The MPTABLE code in Seabios may also need changes to use the right APIC IDs (I am not sure yet). [1] http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/ -- Eduardo