On Mon, 18 Jul 2016 15:05:37 -0600 Eric Blake <ebl...@redhat.com> wrote:
> On 07/14/2016 10:54 AM, Igor Mammedov wrote: > > s/opposit/opposite/ in the subject line, but it's already long. I wonder > if you can go shorter, with: > > pc: enforce CPU add/remove in contiguous order > > > it will still allow us to use cpu_index as migration instance_id > > since when CPUs are added contiguously (from the first to the last) > > and removed in opposite order, cpu_index stays stable and it's > > reproducable on destination side. > > s/reproducable/reproducible/ Eduardo could you fix it up when applying or should I respin it? > > > > Signed-off-by: Igor Mammedov <imamm...@redhat.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. > > I'm not too worried about succeeding only on contiguous ids, as that has > been something libvirt has already had to deal with. But I am a bit > worried about whether it is easy to introspect whether 2.8 adds a way to > hot-plug (or hot-remove) cpus in arbitrary order, with gaps rather than > contiguous ids, especially if the interface does not gain any obvious > parameters. > > If we are going to enhance the interface in the future, do we have any > plans how to make it easily detectable which version of the interface we > are working with (contiguous-only, or full power)? We are discussing on list if we should keep limitation for now and later add means to detect full vs limited interface or go other route and revert limitation patch exposing full interface. Lets wait for feedback from David. Anyway this patch should be applied to be symmetric with what spapr does and if we decide to lift limitation then we should revert it for both spapr and x86.
