All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: agraf@suse.de, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [RFC PATCH v1 06/13] spapr: CPU hotplug support
Date: Fri, 30 Jan 2015 12:29:03 +0530	[thread overview]
Message-ID: <20150130065902.GA24041@in.ibm.com> (raw)
In-Reply-To: <20150123134138.34334599@nial.brq.redhat.com>

On Fri, Jan 23, 2015 at 01:41:38PM +0100, Igor Mammedov wrote:
> On Thu,  8 Jan 2015 11:40:13 +0530
> Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:
> 
> > Support CPU hotplug via device-add command. Use the exising EPOW event
> > infrastructure to send CPU hotplug notification to the guest.
> > 
> > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > ---
> >  hw/ppc/spapr.c              | 205 +++++++++++++++++++++++++++++++++++++++++++-
> >  hw/ppc/spapr_events.c       |   8 +-
> >  target-ppc/translate_init.c |   6 ++
> >  3 files changed, 215 insertions(+), 4 deletions(-)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 515d770..a293a59 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -330,6 +330,8 @@ static void add_str(GString *s, const gchar *s1)
> >      g_string_append_len(s, s1, strlen(s1) + 1);
> >  }
> >  
> > +uint32_t cpus_per_socket;
> static ???

Sure.

> > +
> > +static void spapr_cpu_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> > +                            Error **errp)
> > +{
> > +    Error *local_err = NULL;
> > +    CPUState *cs = CPU(dev);
> > +    PowerPCCPU *cpu = POWERPC_CPU(cs);
> > +    sPAPRDRConnector *drc =
> > +        spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_CPU, cpu->cpu_dt_id);
> just rant: does this have any relation to hotplug_dev, the point here is to get
> these data from hotplug_dev object/some child of it rather then via direct adhoc call.

I see how hotplug_dev is being used to pass on the plug request to ACPI, but
have to check how hotplug_dev can be used more meaningfully here.

> 
> > +
> > +    /* TODO: Check if DR is enabled ? */
> > +    g_assert(drc);
> > +
> > +    spapr_cpu_reset(POWERPC_CPU(CPU(dev)));
> reset probably should be don at realize time, see x86_cpu_realizefn() for example.

Yes, can be done.

> 
> > +    spapr_cpu_hotplug_add(dev, cs);
> > +    spapr_hotplug_req_add_event(drc);
> > +    error_propagate(errp, local_err);
> > +    return;
> > +}
> > +
> > +static void spapr_machine_device_plug(HotplugHandler *hotplug_dev,
> > +                                      DeviceState *dev, Error **errp)
> > +{
> > +    if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
> > +        if (dev->hotplugged) {
> > +            spapr_cpu_plug(hotplug_dev, dev, errp);
> Would be nicer if this could do cold-plugged CPUs wiring too.

Yes, will check and see how intrusive change that would be.

> > diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> > index 9c642a5..cf9d8d3 100644
> > --- a/target-ppc/translate_init.c
> > +++ b/target-ppc/translate_init.c
> > @@ -32,6 +32,7 @@
> >  #include "hw/qdev-properties.h"
> >  #include "hw/ppc/spapr.h"
> >  #include "hw/ppc/ppc.h"
> > +#include "sysemu/sysemu.h"
> >  
> >  //#define PPC_DUMP_CPU
> >  //#define PPC_DEBUG_SPR
> > @@ -8909,6 +8910,11 @@ static void ppc_cpu_realizefn(DeviceState *dev, Error **errp)
> >          return;
> >      }
> >  
> > +    if (cs->cpu_index >= max_cpus) {
> pls note that cpu_index is monotonically increases, so when you do unplug
> and then plug it will go above max_cpus or the same will happen if
> one device_add fails in the middle, the next CPU add will fail because of
> cs->cpu_index goes overboard.
> 
> I'd suggest not to rely/use cpu_index for any purposes and use other means
> to identify where cpu is plugged in. On x68 we slowly getting rid of this
> dependency in favor of apic_id (topology information), eventually it could
> become:
>   -device cpu_foo,socket=X,core=Y[,thread=Z][,node=N]
> 
> you probably could do the same.
> It doesn't have to be in this series, just be aware of potential issues.

I see your point and this needs to be fixed as I see this causing problems
with CPU removal (from the middle) and subsequent addition (which makes
use of "vcpu fd parking and reuse" mechanism).

Thanks for your review.

Regards,
Bharata.

  reply	other threads:[~2015-01-30  6:59 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-08  6:10 [Qemu-devel] [RFC PATCH v1 00/13] CPU and Memory hotplug for PowerPC guests Bharata B Rao
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 01/13] spapr: enable PHB/CPU/LMB hotplug for pseries-2.3 Bharata B Rao
2015-01-22 21:08   ` Michael Roth
2015-01-29  1:04   ` David Gibson
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 02/13] spapr: Add DRC dt entries for CPUs Bharata B Rao
2015-01-22 21:21   ` Michael Roth
2015-01-29  1:04   ` David Gibson
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 03/13] spapr: Consider max_cpus during xics initialization Bharata B Rao
2015-01-29  1:05   ` David Gibson
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 04/13] spapr: Factor out CPU initialization code into realizefn Bharata B Rao
2015-01-29  1:07   ` David Gibson
2015-01-30  7:49     ` Bharata B Rao
2015-02-23  7:36       ` Bharata B Rao
2015-02-23 15:19         ` Alexander Graf
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 05/13] spapr: Support ibm, lrdr-capacity device tree property Bharata B Rao
2015-01-22 21:55   ` Michael Roth
2015-01-30  8:51     ` Bharata B Rao
2015-01-29  1:16   ` David Gibson
2015-01-30  7:50     ` Bharata B Rao
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 06/13] spapr: CPU hotplug support Bharata B Rao
2015-01-22 22:16   ` Michael Roth
2015-01-28  4:19     ` Bharata B Rao
2015-01-28  5:41       ` Michael Roth
2015-01-23 12:41   ` Igor Mammedov
2015-01-30  6:59     ` Bharata B Rao [this message]
2015-01-29  1:31   ` David Gibson
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 07/13] spapr: Start all the threads of CPU core when core is hotplugged Bharata B Rao
2015-01-29  1:36   ` David Gibson
2015-01-30  8:12     ` Bharata B Rao
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 08/13] spapr: Enable CPU hotplug for POWER8 CPU family Bharata B Rao
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 09/13] spapr: CPU hot unplug support Bharata B Rao
2015-01-29  1:39   ` David Gibson
2015-01-30  8:15     ` Bharata B Rao
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 10/13] cpus, spapr: reclaim allocated vCPU objects Bharata B Rao
2015-01-29  1:48   ` David Gibson
2015-01-30  8:23     ` Bharata B Rao
2015-01-31  0:21       ` David Gibson
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 11/13] spapr: Initialize hotplug memory address space Bharata B Rao
2015-02-12  5:19   ` David Gibson
2015-02-12  5:39     ` Bharata B Rao
2015-02-16  4:56       ` David Gibson
2015-02-17  4:00         ` Bharata B Rao
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 12/13] spapr: Support ibm, dynamic-reconfiguration-memory Bharata B Rao
2015-02-12  6:02   ` David Gibson
2015-01-08  6:10 ` [Qemu-devel] [RFC PATCH v1 13/13] spapr: Memory hotplug support Bharata B Rao
2015-02-24  6:26   ` David Gibson
2015-02-24  8:12     ` Bharata B Rao
2015-01-29 17:46 ` [Qemu-devel] [RFC PATCH v1 00/13] CPU and Memory hotplug for PowerPC guests Andreas Färber
2015-02-02  9:00   ` Bharata B Rao
2015-01-29 22:14 ` Tyrel Datwyler

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=20150130065902.GA24041@in.ibm.com \
    --to=bharata@linux.vnet.ibm.com \
    --cc=agraf@suse.de \
    --cc=imammedo@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@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.