[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.
[Qemu-devel] [PATCH v5 04/16] pc: forbid BSP removal, Igor Mammedov, 2016/07/18
[Qemu-devel] [PATCH v4 05/16] pc: enforce adding CPUs contiguously and removing them in opposit order, Igor Mammedov, 2016/07/14
[Qemu-devel] [PATCH v5 05/16] pc: enforce adding CPUs contiguously and removing them in opposit order, Igor Mammedov, 2016/07/18
Re: [Qemu-devel] [PATCH v4 05/16] pc: enforce adding CPUs contiguously and removing them in opposit order, Eric Blake, 2016/07/18
[Qemu-devel] [PATCH v4 06/16] pc: cpu: allow device_add to be used with x86 cpu, Igor Mammedov, 2016/07/14
[Qemu-devel] [PATCH v4 07/16] pc: implement query-hotpluggable-cpus callback, Igor Mammedov, 2016/07/14
[Qemu-devel] [PATCH v4 09/16] apic: drop APICCommonState.idx and use APIC ID as index in local_apics[], Igor Mammedov, 2016/07/14
[Qemu-devel] [PATCH v4 08/16] apic: move MAX_APICS check to 'apic' class, Igor Mammedov, 2016/07/14
[Qemu-devel] [PATCH v4 11/16] (kvm)apic: add unrealize callbacks, Igor Mammedov, 2016/07/14
[Qemu-devel] [PATCH v4 10/16] apic: kvm-apic: fix crash due to access to freed memory region, Igor Mammedov, 2016/07/14