qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 05/16] pc: enforce adding CPUs contiguously a


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v4 05/16] pc: enforce adding CPUs contiguously and removing them in opposit order
Date: Tue, 19 Jul 2016 14:25:19 +0200

On Mon, 18 Jul 2016 15:05:37 -0600
Eric Blake <address@hidden> 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 <address@hidden>
> > ---
> > 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]