From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLBmr-0003Zk-CN for qemu-devel@nongnu.org; Thu, 07 Jul 2016 12:04:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLBmn-0000Yf-6L for qemu-devel@nongnu.org; Thu, 07 Jul 2016 12:04:24 -0400 Received: from 4.mo69.mail-out.ovh.net ([46.105.42.102]:39967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLBmm-0000YM-Sj for qemu-devel@nongnu.org; Thu, 07 Jul 2016 12:04:21 -0400 Received: from player779.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id A1C501010ED6 for ; Thu, 7 Jul 2016 18:04:19 +0200 (CEST) Date: Thu, 7 Jul 2016 18:04:10 +0200 From: Greg Kurz Message-ID: <20160707180410.351fb5eb@bahia.lan> In-Reply-To: <1467903025-13383-1-git-send-email-bharata@linux.vnet.ibm.com> References: <1467903025-13383-1-git-send-email-bharata@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 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: Bharata B Rao Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, david@gibson.dropbear.id.au, imammedo@redhat.com, nikunj@linux.vnet.ibm.com, pbonzini@redhat.com On Thu, 7 Jul 2016 20:20:20 +0530 Bharata B Rao wrote: > 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. > > - CPUState::stable_cpu_id is newly introduced and used as instance_id when > registering CPU devices using vmstate_register. stable_cpu_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 stable_cpu_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 (which is stable_cpu_id for pseries-2.7 onwards) > based on core-id and hence is based on ppc-vcpu-dt-id-rework branch of his > tree. > I'm not very comfortable with this. Shouldn't it be the other way round actually: cpu_dt_id depending on stable_cpu_id ? I think we're missing something like a stable_core_id. I'll illustrate that with a comment on patch 3/5. > Changes in v2 > ------------- > - s/migration_id/stable_cpu_id and this is set by the machine code > after CPU init but before realize. > - s/use-migration-id/has-migration-id and use DEFINE_PROP_BOOL to simplify > the code. > - Start with use-migration-id turned off by default. > - Consolidate the code that obtains the 'server' in XICS code into a > separate routine. > > v1: https://www.mail-archive.com/qemu-devel@nongnu.org/msg384135.html > > Bharata B Rao (5): > cpu,target-ppc: Move cpu_vmstate_[un]register calls to > cpu_common_[un]realize > cpu: Introduce CPUState::stable_cpu_id > spapr: Set stable_cpu_id for threads of CPU cores > xics: Use stable_cpu_id instead of cpu_index in XICS code > spapr: Enable the use of stable_cpu_id from pseries-2.7 onwards > > exec.c | 55 ++++++++++++++++++++++++++++----------------- > hw/intc/xics.c | 21 +++++++++++++---- > hw/intc/xics_kvm.c | 10 ++++----- > hw/intc/xics_spapr.c | 29 ++++++++++++++---------- > hw/ppc/spapr.c | 14 ++++++++++++ > hw/ppc/spapr_cpu_core.c | 7 ++++++ > include/hw/compat.h | 3 +++ > include/hw/ppc/xics.h | 1 + > include/qom/cpu.h | 7 ++++++ > qom/cpu.c | 13 +++++++++++ > target-ppc/cpu-qom.h | 2 ++ > target-ppc/translate_init.c | 3 +++ > 12 files changed, 123 insertions(+), 42 deletions(-) >