From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKigI-0007XV-Fz for qemu-devel@nongnu.org; Wed, 06 Jul 2016 04:59:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKigE-00054a-Am for qemu-devel@nongnu.org; Wed, 06 Jul 2016 04:59:41 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:13543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKigE-00054N-1q for qemu-devel@nongnu.org; Wed, 06 Jul 2016 04:59:38 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u668wxVa009271 for ; Wed, 6 Jul 2016 04:59:37 -0400 Received: from e28smtp06.in.ibm.com (e28smtp06.in.ibm.com [125.16.236.6]) by mx0a-001b2d01.pphosted.com with ESMTP id 240nk9f1t9-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 06 Jul 2016 04:59:36 -0400 Received: from localhost by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Jul 2016 14:29:33 +0530 From: Bharata B Rao Date: Wed, 6 Jul 2016 14:29:16 +0530 Message-Id: <1467795561-1007-1-git-send-email-bharata@linux.vnet.ibm.com> Subject: [Qemu-devel] [RFC PATCH v1 0/5] sPAPR: Fix migration when CPUs are removed in random order List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, david@gibson.dropbear.id.au, imammedo@redhat.com, groug@kaod.org, nikunj@linux.vnet.ibm.com, pbonzini@redhat.com, Bharata B Rao 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. - migration_id is newly introduced and used as instance_id when registering CPU devices using vmstate_register. migration_id is set by the target machine code. 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 migration_id for migration as well as in XICS code. vmstate registration calls are moved to cpu_common_realizefn and newly introduced cpu_common_unrealizefn. 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. Changes in v1 ------------- - Introduced CPUState::migration_id to be used with vmstate_register() - migration_id is now set by target machine code via CPUClass::get_migration_id() - Use of migration is controlled by a property CPUState:use_migration_id. - Use of SPAPR_COMPAT_2_6 to set use-migration-id property for all CPUs starting from pseries-2.7 onwards. - Calling vmstate_[un]register() from cpu_common_[un]realizefn calls. v0: http://lists.nongnu.org/archive/html/qemu-ppc/2016-07/msg00090.html Bharata B Rao (5): cpu,target-ppc: Move cpu_vmstate_[un]register calls to cpu_common_[un]realize cpu: Introduce CPUState::migration_id spapr: Implement CPUClass::get_migration_id() for PowerPC CPUs xics: Use migration_id instead of cpu_index in XICS code cpu,spapr: Use migration_id from pseries-2.7 onwards exec.c | 54 ++++++++++++++++++++++++++++----------------- hw/intc/xics.c | 12 ++++++---- hw/intc/xics_kvm.c | 11 +++++---- hw/intc/xics_spapr.c | 28 +++++++++++++++++------ hw/ppc/spapr.c | 5 +++++ include/qom/cpu.h | 8 +++++++ qom/cpu.c | 29 ++++++++++++++++++++++++ target-ppc/cpu-qom.h | 2 ++ target-ppc/translate_init.c | 15 +++++++++++++ 9 files changed, 127 insertions(+), 37 deletions(-) -- 2.7.4