All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Bharata B Rao <bharata@linux.vnet.ibm.com>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/1] spapr: Ensure CPU cores are added contiguously and removed in LIFO order
Date: Wed, 13 Jul 2016 11:20:23 +0200	[thread overview]
Message-ID: <20160713112023.2192fe5a@bahia.lan> (raw)
In-Reply-To: <20160713094254.04658871@nial.brq.redhat.com>

On Wed, 13 Jul 2016 09:42:54 +0200
Igor Mammedov <imammedo@redhat.com> wrote:

> On Wed, 13 Jul 2016 12:20:20 +0530
> Bharata B Rao <bharata@linux.vnet.ibm.com> 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.  
> Adding this limitation looks better than adding migration_id as
> it will allow libvirt to use the current -numa cpus=... while
> doing the same amount of guess work as it does now.
> 
> Similar patch for x86 won't be so simple as cpu-add can add cpus
> with gaps (breaking migration at that), so I'd need to keep it
> that way with some compat code, but that shouldn't be issue.
> 

And does libvirt take care not to add cpus with gaps ? If so, maybe it
can do the same with PPC, and we'd simply warn the user that migration
is broken if we introduce gaps. Makes sense ?

> 
> > Signed-off-by: Bharata B Rao <bharata@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.
> > 
> >  hw/ppc/spapr_cpu_core.c | 21 ++++++++++++++++++++-
> >  1 file changed, 20 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> > index bc52b3c..4bfc96b 100644
> > --- a/hw/ppc/spapr_cpu_core.c
> > +++ b/hw/ppc/spapr_cpu_core.c
> > @@ -126,12 +126,23 @@ static void spapr_core_release(DeviceState *dev, void *opaque)
> >  void spapr_core_unplug(HotplugHandler *hotplug_dev, DeviceState *dev,
> >                         Error **errp)
> >  {
> > +    sPAPRMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
> >      CPUCore *cc = CPU_CORE(dev);
> >      sPAPRDRConnector *drc =
> >          spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_CPU, cc->core_id);
> >      sPAPRDRConnectorClass *drck;
> >      Error *local_err = NULL;
> > +    int smt = kvmppc_smt_threads();
> > +    int index = cc->core_id / smt;
> > +    int spapr_max_cores = max_cpus / smp_threads;
> > +    int i;
> >  
> > +    for (i = spapr_max_cores - 1; i > index; i--) {
> > +        if (spapr->cores[i]) {
> > +            error_setg(errp, "core-id %d should be removed first", i * smt);
> > +            return;
> > +        }
> > +    }
> >      g_assert(drc);
> >  
> >      drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> > @@ -214,7 +225,7 @@ void spapr_core_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> >      sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(OBJECT(hotplug_dev));
> >      sPAPRMachineState *spapr = SPAPR_MACHINE(OBJECT(hotplug_dev));
> >      int spapr_max_cores = max_cpus / smp_threads;
> > -    int index;
> > +    int index, i;
> >      int smt = kvmppc_smt_threads();
> >      Error *local_err = NULL;
> >      CPUCore *cc = CPU_CORE(dev);
> > @@ -252,6 +263,14 @@ void spapr_core_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> >          goto out;
> >      }
> >  
> > +    for (i = 0; i < index; i++) {
> > +        if (!spapr->cores[i]) {
> > +            error_setg(&local_err, "core-id %d should be added first",
> > +                       i * smt);
> > +            goto out;
> > +        }
> > +    }
> > +
> >  out:
> >      g_free(base_core_type);
> >      error_propagate(errp, local_err);  
> 
> 

  parent reply	other threads:[~2016-07-13  9:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-13  6:50 [Qemu-devel] [PATCH 1/1] spapr: Ensure CPU cores are added contiguously and removed in LIFO order Bharata B Rao
2016-07-13  7:42 ` Igor Mammedov
2016-07-13  8:19   ` Igor Mammedov
2016-07-13  8:23     ` Igor Mammedov
2016-07-13  9:20   ` Greg Kurz [this message]
2016-07-14  0:51 ` David Gibson
2016-07-14  8:27   ` Igor Mammedov
2016-07-15  5:29     ` David Gibson
2016-07-15  5:35       ` Bharata B Rao
2016-07-15  9:15       ` Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160713112023.2192fe5a@bahia.lan \
    --to=groug@kaod.org \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=imammedo@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.