On Fri, Jul 15, 2016 at 03:29:01PM +1000, David Gibson wrote: > On Thu, Jul 14, 2016 at 10:27:15AM +0200, Igor Mammedov wrote: > > On Thu, 14 Jul 2016 10:51:27 +1000 > > David Gibson <da...@gibson.dropbear.id.au> wrote: > > > > > 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), migration > > > > can fail as migration with holes in cpu_index range isn't yet handled > > > > correctly. > > > > > > > > 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. > > > > > > > > Signed-off-by: Bharata B Rao <bhar...@linux.vnet.ibm.com> > > > > --- > > > > While there is work in progress to support migration when there are > > > > holes > > > > in cpu_index range resulting from out-of-order plug or unplug, this > > > > patch > > > > is intended as a last resort if no easy, risk-free and elegant solution > > > > emerges before 2.7 dev cycle ends. > > > > > > 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.
Right. I too thought that when we relax this restriction say in 2.8, we could have a sPAPRMachineClass option to allow out-of-order hotplug for 2.8 upwards and disable it for 2.7 downwards. With this, 2.7 guest started with new-qemu can be migrated to old-qemu. Regards, Bharata.
