From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNvem-00056t-St for qemu-devel@nongnu.org; Fri, 15 Jul 2016 01:27:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNvei-0007Rx-JX for qemu-devel@nongnu.org; Fri, 15 Jul 2016 01:27:24 -0400 Date: Fri, 15 Jul 2016 15:29:01 +1000 From: David Gibson Message-ID: <20160715052901.GW14615@voom.fritz.box> References: <1468392620-25599-1-git-send-email-bharata@linux.vnet.ibm.com> <20160714005127.GH14615@voom.fritz.box> <20160714102715.303950e4@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jfWagoTHmfL/c8Ax" Content-Disposition: inline In-Reply-To: <20160714102715.303950e4@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [PATCH 1/1] spapr: Ensure CPU cores are added contiguously and removed in LIFO order List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Bharata B Rao , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, groug@kaod.org --jfWagoTHmfL/c8Ax Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 14, 2016 at 10:27:15AM +0200, Igor Mammedov wrote: > On Thu, 14 Jul 2016 10:51:27 +1000 > David Gibson wrote: >=20 > > On Wed, Jul 13, 2016 at 12:20:20PM +0530, Bharata B Rao wrote: > > > If CPU core addition or removal is allowed in random order leading to > > > holes in the core id range (and hence in the cpu_index range), migrat= ion > > > can fail as migration with holes in cpu_index range isn't yet handled > > > correctly. > > >=20 > > > Prevent this situation by enforcing the addition in contiguous order > > > and removal in LIFO order so that we never end up with holes in > > > cpu_index range. > > >=20 > > > Signed-off-by: Bharata B Rao > > > --- > > > While there is work in progress to support migration when there are h= oles > > > in cpu_index range resulting from out-of-order plug or unplug, this p= atch > > > is intended as a last resort if no easy, risk-free and elegant soluti= on > > > emerges before 2.7 dev cycle ends. =20 > >=20 > > Applied to ppc-for-2.7. We can revert it once the problems with > > cpu_index are sorted out. > You'd need to add machine type specific compat option here, > so that new-qemu -M 2.7 wouldn't allow out of order too and > could be migrated to old-qemu -M 2.7 Hmm, do we care about migration from newer back to older versions of qemu upstream? If so, then I guess we do need this option. Though strictly we don't need it until we actually do allow any-order hotplug. --=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 --jfWagoTHmfL/c8Ax Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXiHSdAAoJEGw4ysog2bOSS24QAMcI/iTybX4RmiioaU3OsSUA 6470Fqa9tAF2MviEfLFl5ebBWGYvoT5kzujR7xnEqCKfsfabqzyl1oI97156j7oo 8L2xZ59pF3Yi7VPcHqiBSGCA/wN3gQy2MGRIJDks9DdzDxsth1fifJJxvKE46KZ1 xC2oY4YwYdw6cgnZmlvWb5aoveJlXyZVZdrgZHQSv4AEr3brALzsAXp54l4tO2g8 wXGnMGpnS+usxrzC7GkGU+XVf33djEKMxBde+Uuh+73dntTS0YRS8XeNv0kw4UkK W+VWgzyCQHWuiBdlW8ZhYprHPeK5Yi2VrRSejwhHHlBOxzey0dHL9wk9eh12ebH/ PiTZL7ZAf4iLmRqdbJovRn70+a7NGzu1+o54qsFXs5/uUVXpDQA1uZ7qTB0DlDdC MmTLgaczgpe+LWzuvYJDB5kK5KrYpCuOVYSyXY2N7mFevZx5Ztzu7F/NFMTcnJxd Od9IiRCkLN9lI7TRMUTkU/Fz508SLA+Q15EZG3MvLTZjLoMRbI8A7n+1N9cJnx5k gLCDMOxP+6uTi+Qi/OMVN0H/QfVKlW/RorY9jcVh8/+ZazVFDZGDk85XtqcRbb6o EzBqQ+H+QX5FzxOHve1XCXHKMHJCtjXE9TzLM0w5/BFc7Dh9407c2yskVZqW0oGW vKgLL0fNNzHUo0lkbR9s =ontw -----END PGP SIGNATURE----- --jfWagoTHmfL/c8Ax--