[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [RFC 0/7+1] QEMU APIC ID + topology bug + CPU hotplug
From: |
Eduardo Habkost |
Subject: |
[Qemu-devel] [RFC 0/7+1] QEMU APIC ID + topology bug + CPU hotplug |
Date: |
Tue, 10 Jul 2012 17:22:15 -0300 |
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
- [Qemu-devel] [RFC 0/7+1] QEMU APIC ID + topology bug + CPU hotplug,
Eduardo Habkost <=
[Qemu-devel] [Seabios RFC PATCH 1/1] get lapic IDs from fw_cfg, Eduardo Habkost, 2012/07/10
[Qemu-devel] [QEMU RFC PATCH 4/7] i386: create apic_id_for_cpu() function, Eduardo Habkost, 2012/07/10
[Qemu-devel] [QEMU RFC PATCH 7/7] generate APIC IDs according to CPU topology, Eduardo Habkost, 2012/07/10
[Qemu-devel] [QEMU RFC PATCH 6/7] i386: topology & APIC ID utility functions, Eduardo Habkost, 2012/07/10