[Qemu-devel] [RFC 0/7+1] QEMU APIC ID + topology bug + CPU hotplug

[Eduardo Habkost <ehabkost@redhat.com>]

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