device_add/del based CPU hotplug and unplug support is upstream for sPAPR PowerPC and is under development for x86. Both of these will support CPU device removal in random order (and not necessarily in LIFO order). Random order removal will result in holes in cpu_index range which causes migration to fail. This needs fixes in both generic code as well as arch specific code.
- We need to use arch_id as the instance_id when registering CPU devices using vmstate_register. To support forward migration, as per Igor's suggestion, this needs to be done conditionally based on machine type version. - From pseries-2.7 onwards, we start using arch_id for migration as well as in XICS code. In fact, Igor even suggested to move the vmstate registration calls into cpu_common_realizefn and yet-to-be-introduced cpu_common_unrealizefn. But I haven't done that in this patchset as I am hitting an unrelated issue with that movement. This patchset depends on Greg Kurz's patchset where among other things, he is deriving cpu_dt_it (arch_id) based on core-id. (https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg00210.html) Tested changes to XICS code with both kernel_irqchip=on/off. This applies on ppc-for-2.7 branch of David's tree. Bharata B Rao (5): cpu: Factor out cpu vmstate_[un]register into separate routines cpu: Optionally use arch_id instead of cpu_index in cpu vmstate_register() spapr: Implement CPUClass.get_arch_id() for PowerPC CPUs xics: Use arch_id instead of cpu_index in XICS code spapr: Prefer arch_id over cpu_index exec.c | 53 +++++++++++++++++++++++++++++---------------- hw/intc/xics.c | 14 ++++++++---- hw/intc/xics_kvm.c | 12 +++++----- hw/intc/xics_spapr.c | 33 ++++++++++++++++++++++------ hw/ppc/spapr.c | 2 ++ hw/ppc/spapr_cpu_core.c | 5 +++++ include/hw/boards.h | 1 + include/qom/cpu.h | 4 ++++ target-ppc/translate_init.c | 8 +++++++ 9 files changed, 96 insertions(+), 36 deletions(-) -- 2.7.4
