qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: mjrosato@linux.vnet.ibm.com, agraf@suse.de, thuth@redhat.com,
	pkrempa@redhat.com, ehabkost@redhat.com, aik@ozlabs.ru,
	qemu-devel@nongnu.org, armbru@redhat.com, borntraeger@de.ibm.com,
	qemu-ppc@nongnu.org, pbonzini@redhat.com,
	Igor Mammedov <imammedo@redhat.com>,
	mdroth@linux.vnet.ibm.com, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH v2 4/5] spapr: check if cpu core is already present
Date: Thu, 10 Mar 2016 11:32:44 +0530	[thread overview]
Message-ID: <20160310060244.GB745@in.ibm.com> (raw)
In-Reply-To: <20160310052243.GW22546@voom.fritz.box>

On Thu, Mar 10, 2016 at 04:22:43PM +1100, David Gibson wrote:
> On Wed, Mar 09, 2016 at 11:07:40AM +0100, Igor Mammedov wrote:
> > On Tue, 8 Mar 2016 20:04:12 +0530
> > Bharata B Rao <bharata@linux.vnet.ibm.com> wrote:
> > 
> > > On Tue, Mar 08, 2016 at 02:18:14PM +0100, Igor Mammedov wrote:
> > > > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > > > ---
> > > > replaced link set check removed in previous patch
> > > > ---
> > > >  hw/ppc/spapr.c | 26 ++++++++++++++++++++++----
> > > >  1 file changed, 22 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > index 6890a44..db33c29 100644
> > > > --- a/hw/ppc/spapr.c
> > > > +++ b/hw/ppc/spapr.c
> > > > @@ -2297,6 +2297,27 @@ void *spapr_populate_hotplug_cpu_dt(DeviceState *dev, CPUState *cs,
> > > >      return fdt;
> > > >  }
> > > > 
> > > > +static void spapr_machine_device_pre_plug(HotplugHandler *hotplug_dev,
> > > > +                                          DeviceState *dev, Error **errp)
> > > > +{
> > > > +    sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(hotplug_dev);
> > > > +    sPAPRMachineState *spapr = SPAPR_MACHINE(hotplug_dev);
> > > > +
> > > > +    if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_CPU_CORE)) {
> > > > +        int core = object_property_get_int(OBJECT(dev), CPU_CORE_ID_PROP,
> > > > +                                           &error_abort);
> > > > +
> > > > +        if (!smc->dr_cpu_enabled && dev->hotplugged) {
> > > > +            error_setg(errp, "CPU hotplug not supported for this machine");
> > > > +            return;
> > > > +        }
> > > > +        if (spapr->cores[core]) {
> > > > +            error_setg(errp, "core %d is already present", core);
> > > > +            return;
> > > > +        }  
> > > 
> > > Wondering why can't we do the above check from core's realizefn and fail
> > > the core hotplug from realizefn ?
> > that's rather simple, in ideal QOM world child shouldn't
> > poke into parents internal if it could be helped.
> > So hook provides responsibility separation where
> > board/or something else(HotplugHandler) can do a necessary
> > wiring of a component which is being hotplugged, without
> > forcing hotplugged device being aware about it.
> 
> Oh.. yes.  Sorry, somehow I got confused and thought you were
> suggesting a 'pre_realize()' method on the *object* rather than a
> pre_plug hotplughandler hook.
> 
> > That's what HotplugHandler->plug callback is doing for
> > post realize and HotplugHandler->pre_plug will do similar
> > thing but allowing board to execute preliminary tasks
> > (like check/set properties, amend its internal state)
> > before object is realized.
> 
> > That will make realize() cleaner as it won't have to hack
> > into data it shouldn't and would prevent us calling unrealize()
> > if we were to check it later at HotplugHandler->plug time.
> > (i.e. realize() won't even have a chance to introduce side
> > effects that should be undone with unlealize())
> 
> Hmm.. how big a deal is it to roll back from the existing plug()
> handler?

Since plug() handler is post-realize, rolling back involves
deleting the threads of the core we created and finally deleting the core
itself. We aleady do this kind of roll back when core hotplug is attemptedi
on machine type version that don't support hotplug.

For the present case of rejecting the hotplug for duplicate core_ids,
are you in fact hinting that instead of failing the hotplug in pre_plug()
lets realize then and then roll back from plug() ?

Regards,
Bharata.

  reply	other threads:[~2016-03-10  6:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-08 13:18 [Qemu-devel] [PATCH v2 0/5] spapr: QMP: add query-hotpluggable-cpus Igor Mammedov
2016-03-08 13:18 ` [Qemu-devel] [PATCH v2 1/5] " Igor Mammedov
2016-03-08 16:46   ` Eric Blake
2016-03-09  3:15     ` David Gibson
2016-03-09  9:34     ` Igor Mammedov
2016-03-08 13:18 ` [Qemu-devel] [PATCH v2 2/5] spapr: convert slot name property to numeric core and links Igor Mammedov
2016-03-08 15:09   ` Bharata B Rao
2016-03-09  9:27     ` Igor Mammedov
2016-03-08 16:48   ` Eric Blake
2016-03-09  9:40     ` Igor Mammedov
2016-03-09  3:19   ` David Gibson
2016-03-09  9:48     ` Igor Mammedov
2016-03-08 13:18 ` [Qemu-devel] [PATCH v2 3/5] qdev: hotplug: introduce HotplugHandler.pre_plug() callback Igor Mammedov
2016-03-08 13:18 ` [Qemu-devel] [PATCH v2 4/5] spapr: check if cpu core is already present Igor Mammedov
2016-03-08 14:34   ` Bharata B Rao
2016-03-09 10:07     ` Igor Mammedov
2016-03-10  5:22       ` David Gibson
2016-03-10  6:02         ` Bharata B Rao [this message]
2016-03-10 10:39           ` Igor Mammedov
2016-03-10 14:45             ` Bharata B Rao
2016-03-11 10:31               ` Igor Mammedov
2016-03-15  6:10             ` David Gibson
2016-03-15 11:05               ` Igor Mammedov
2016-03-15 23:38                 ` David Gibson
2016-03-16 15:26                   ` Igor Mammedov
2016-03-08 13:18 ` [Qemu-devel] [PATCH v2 5/5] spapr: implement query-hotpluggable-cpus QMP command 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=20160310060244.GB745@in.ibm.com \
    --to=bharata@linux.vnet.ibm.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=armbru@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mjrosato@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=thuth@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).