From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLOP4-0002Yk-Ke for qemu-devel@nongnu.org; Fri, 08 Jul 2016 01:32:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLOP2-0007S6-Di for qemu-devel@nongnu.org; Fri, 08 Jul 2016 01:32:41 -0400 Date: Fri, 8 Jul 2016 15:34:20 +1000 From: David Gibson Message-ID: <20160708053420.GP14675@voom.fritz.box> References: <1467903025-13383-1-git-send-email-bharata@linux.vnet.ibm.com> <20160707180410.351fb5eb@bahia.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0WzQiIesntPPsVaS" Content-Disposition: inline In-Reply-To: <20160707180410.351fb5eb@bahia.lan> 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: Greg Kurz Cc: Bharata B Rao , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, imammedo@redhat.com, nikunj@linux.vnet.ibm.com, pbonzini@redhat.com --0WzQiIesntPPsVaS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 07, 2016 at 06:04:10PM +0200, Greg Kurz wrote: > On Thu, 7 Jul 2016 20:20:20 +0530 > Bharata B Rao wrote: >=20 > > 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. > >=20 > > - CPUState::stable_cpu_id is newly introduced and used as instance_id w= hen > > 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. > >=20 > > vmstate registration calls are moved to cpu_common_realizefn and newly > > introduced cpu_common_unrealizefn. > >=20 > > 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 onward= s) > > based on core-id and hence is based on ppc-vcpu-dt-id-rework branch of = his > > tree. > >=20 >=20 > I'm not very comfortable with this. Shouldn't it be the other way round > actually: cpu_dt_id depending on stable_cpu_id ? >=20 > I think we're missing something like a stable_core_id. The core-id is already stable. Deriving the stable vcpu id from the core id is correct. cpu_dt_id should actually go away, and we should just use stable_cpu_id when creating the device tree. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --0WzQiIesntPPsVaS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXfztcAAoJEGw4ysog2bOSOisQANDgwccjx06k13pdfn9cY0ek bkN5QwMcckqCy0hO2v2Y5/GFyz2pm5sHsT1M4tSVgwUSWmQKTi3zkevCwUjw9b+9 FVkLRqn94oJY+J5dDg2oG04EGYU8Rpe09htnpThDrjiNg8AjFSpPaoLT5OWh1e1r 63RljJ5mv6Le99ZuMzBXKRgEjFzI0PtBidTxyANHrH1t7TgcVCAHPb/6mxQ3/+gm ZhEpCqByJILHEiPUj03dIhSKgr3MCtT3TIGz2Mw566EnzM/JJPyWZ7tS8/YMqu1/ 6oN3xfZ6lyOXul/KWJaYwUoz4qxT3pHrIBc3vSxUx1P/OG00kgcphjIyrQGCxmlM +FJ1wcAbQ06ro5fbUdTkxIEtPR2pwsb+3blt92t0256jSysMFwmF6/Ir+ZFEYQL1 7lWeRq54yKPux3XRVx3uGsx1MAzocVyDPm5p2SQCUnWfdDzrMYWHdBXvnBbxFd4f 7RZm8acELKBosxpps0eEdHSfi+WWp2lDMytuabYEUUuPbP+26COhBrC6dIGGEBSH 8gF1jqUTWHDzj5XofkPSX6gJVuNU9RaZAauhIJLA+oBi2Fr1EHcBarseRUPjpxpQ vyQwcP3xIKo3uvumiOqv6Sw36sZfZpj3oo95WORnZ/4prR9s01ZSF8dRIpVsRoM7 Do3OWuh8qg7HArCRgpAF =HZEm -----END PGP SIGNATURE----- --0WzQiIesntPPsVaS--