From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: bharata@linux.vnet.ibm.comBharata B Rao <bharata@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, agraf@suse.de, qemu-ppc@nongnu.org,
tyreld@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com,
imammedo@redhat.com, david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [RFC PATCH v0 3/3] spapr: Memory hot-unplug support
Date: Fri, 04 Sep 2015 11:06:00 -0500 [thread overview]
Message-ID: <20150904160600.10296.13169@loki> (raw)
In-Reply-To: <20150826095750.GB11136@in.ibm.com>
Quoting Bharata B Rao (2015-08-26 04:57:51)
> On Mon, Aug 24, 2015 at 09:39:31PM -0500, Michael Roth wrote:
> > Quoting Bharata B Rao (2015-08-19 01:56:11)
> > > Add support to hot remove pc-dimm memory devices.
> > >
> > > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > > ---
> > > hw/ppc/spapr.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++-
> > > hw/ppc/spapr_drc.c | 21 +++++++++
> > > include/hw/ppc/spapr.h | 2 +
> > > 3 files changed, 136 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > index 06d000d..441012d 100644
> > > --- a/hw/ppc/spapr.c
> > > +++ b/hw/ppc/spapr.c
> > > @@ -2110,6 +2110,109 @@ out:
> > > error_propagate(errp, local_err);
> > > }
> > >
> > > +typedef struct sPAPRDIMMState {
> > > + uint32_t nr_lmbs;
> > > +} sPAPRDIMMState;
> > > +
> > > +/*
> > > + * Called from spapr_drc.c: set_isolation_state().
> > > + *
> > > + * If the drc is being marked as ISOLATED, ensure that the corresponding
> > > + * LMB is part of the DIMM device which is being deleted.
> > > + */
> > > +int spapr_lmb_in_removable_dimm(sPAPRDRConnector *drc,
> > > + sPAPRDRIsolationState state)
> > > +{
> > > + DeviceState *dev = drc->dev;
> > > + PCDIMMDevice *dimm = PC_DIMM(dev);
> > > +
> > > + if (state != SPAPR_DR_ISOLATION_STATE_ISOLATED) {
> > > + return 0;
> > > + }
> > > +
> > > + if (!dimm->delete_pending) {
> > > + return -1;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void spapr_lmb_release(DeviceState *dev, void *opaque)
> > > +{
> > > + sPAPRDIMMState *ds = (sPAPRDIMMState *)opaque;
> > > + HotplugHandler *hotplug_ctrl = NULL;
> > > + Error *local_err = NULL;
> > > +
> > > + if (--ds->nr_lmbs) {
> > > + return;
> > > + }
> > > +
> > > + g_free(ds);
> > > +
> > > + /*
> > > + * Now that all the LMBs have been removed by the guest, call the
> > > + * pc-dimm unplug handler to cleanup up the pc-dimm device.
> > > + */
> > > + hotplug_ctrl = qdev_get_hotplug_handler(dev);
> > > + hotplug_handler_unplug(hotplug_ctrl, dev, &local_err);
> > > +}
> > > +
> > > +static void spapr_del_lmbs(DeviceState *dev, uint64_t addr, uint64_t size,
> > > + Error **errp)
> > > +{
> > > + sPAPRDRConnector *drc;
> > > + sPAPRDRConnectorClass *drck;
> > > + uint32_t nr_lmbs = size/SPAPR_MEMORY_BLOCK_SIZE;
> > > + Error *local_err = NULL;
> > > + int i;
> > > + sPAPRDIMMState *ds = g_malloc0(sizeof(sPAPRDIMMState));
> > > +
> > > + ds->nr_lmbs = nr_lmbs;
> > > + for (i = 0; i < nr_lmbs; i++) {
> > > + drc = spapr_dr_connector_by_id(SPAPR_DR_CONNECTOR_TYPE_LMB,
> > > + addr/SPAPR_MEMORY_BLOCK_SIZE);
> > > + g_assert(drc);
> > > +
> > > + drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> > > + drck->detach(drc, dev, spapr_lmb_release, ds, &local_err);
> > > + addr += SPAPR_MEMORY_BLOCK_SIZE;
> > > + }
> > > + spapr_hotplug_req_remove_by_count(SPAPR_DR_CONNECTOR_TYPE_LMB, nr_lmbs);
> > > +}
> > > +
> > > +static void spapr_memory_unplug(HotplugHandler *hotplug_dev, DeviceState *dev,
> > > + Error **errp)
> > > +{
> > > + sPAPRMachineState *ms = SPAPR_MACHINE(hotplug_dev);
> > > + PCDIMMDevice *dimm = PC_DIMM(dev);
> > > + PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
> > > + MemoryRegion *mr = ddc->get_memory_region(dimm);
> > > +
> > > + pc_dimm_memory_unplug(dev, &ms->hotplug_memory, mr);
> > > + object_unparent(OBJECT(dev));
> > > +}
> >
> > In the current code the unplug() and request_unplug() are mutually
> > exclusive. Are the plans on making the unplug() do something in the
> > prescence of request_unplug()? If so, I'd imagine it would've be a
> > forced removal, except maybe as a fallback if the request is determined
> > to fail somehow?
>
> Like x86 memory hotremoval, our model too fits into async type of removal
> where we first send removal notification to guest in ->unplug_request() and
> when the guest indeed removes the memory, we cleanup the pc-dimm device
> in ->unplug().
>
> Since we implement both ->unplug() and ->unplug_request(), and given that
> the removal works like above, I don't see why we would ever end up doing a
> forced removal from ->unplug().
Ah, sorry, misunderstanding on my part: as far as *qdev* lifecycle is
concerned, unplug() never gets called directly if unplug_request() is
defined, so it seemed the 2 were mutually exclusive. But in the case
of memory x86 unplug, unplug_request()'s implementation is such that
the unplug() handler gets called explicitly via guest acknowledgement's
callback, which is the same as what you've modelled here.
It's a little wierd that the unplug() callback is needlessly exposed
outside of the async unplug_request() implementation, but it does
allow for future code where maybe a --force option could be introduced
for certain situations where a guest isn't cooperative.
>
> > > diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
> > > index 8cbcf4d..b9d7c71 100644
> > > --- a/hw/ppc/spapr_drc.c
> > > +++ b/hw/ppc/spapr_drc.c
> > > @@ -11,6 +11,7 @@
> > > */
> > >
> > > #include "hw/ppc/spapr_drc.h"
> > > +#include "hw/ppc/spapr.h"
> > > #include "qom/object.h"
> > > #include "hw/qdev.h"
> > > #include "qapi/visitor.h"
> > > @@ -63,9 +64,29 @@ static int set_isolation_state(sPAPRDRConnector *drc,
> > > sPAPRDRIsolationState state)
> > > {
> > > sPAPRDRConnectorClass *drck = SPAPR_DR_CONNECTOR_GET_CLASS(drc);
> > > + int ret;
> > >
> > > DPRINTFN("drc: %x, set_isolation_state: %x", get_index(drc), state);
> > >
> > > + /*
> > > + * Fail any requests to ISOLATE the LMB DRC if this LMB doesn't
> > > + * belong to a DIMM device that is marked for removal.
> > > + *
> > > + * Currently the guest userspace tool drmgr that drives the memory
> > > + * hotplug/unplug will just try to remove a set of 'removable' LMBs
> > > + * in response to a hot unplug request that is based on drc-count.
> > > + * If the LMB being removed doesn't belong to a DIMM device that is
> > > + * actually being unplugged, fail the isolation request here.
> > > + *
> > > + * TODO: Calling out from spapr_drc.c like this doesn't look good.
> > > + */
> > > + if (drc->type == SPAPR_DR_CONNECTOR_TYPE_LMB) {
> > > + ret = spapr_lmb_in_removable_dimm(drc, state);
> > > + if (ret) {
> > > + return RTAS_OUT_HW_ERROR;
> > > + }
> > > + }
>
> I am not sure if this call out is the right way to do this. Do you have
> suggestions here ?
Since drc->awaiting_release is only set in cases where the corresponding
dimm is pending delete, I think maybe we can rely on
drc->awaiting_release instead and avoid the call out.
>
> Regards,
> Bharata.
>
next prev parent reply other threads:[~2015-09-04 16:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-19 6:56 [Qemu-devel] [RFC PATCH v0 0/3] sPAPR: Memory hot removal support Bharata B Rao
2015-08-19 6:56 ` [Qemu-devel] [RFC PATCH v0 1/3] pc-dimm: Add a field to PCDIMMDevice to mark device deletion state Bharata B Rao
2015-08-25 2:30 ` Michael Roth
2015-08-26 4:32 ` Bharata B Rao
2015-08-19 6:56 ` [Qemu-devel] [RFC PATCH v0 2/3] spapr-rtas: Enable rtas_set_indicator() to return correct error Bharata B Rao
2015-08-25 2:26 ` Michael Roth
2015-09-04 7:10 ` David Gibson
2015-08-19 6:56 ` [Qemu-devel] [RFC PATCH v0 3/3] spapr: Memory hot-unplug support Bharata B Rao
2015-08-25 2:39 ` Michael Roth
2015-08-26 9:57 ` Bharata B Rao
2015-09-04 16:06 ` Michael Roth [this message]
2015-09-04 7:20 ` David Gibson
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=20150904160600.10296.13169@loki \
--to=mdroth@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=bharata@linux.vnet.ibm.comBharata \
--cc=david@gibson.dropbear.id.au \
--cc=imammedo@redhat.com \
--cc=nfont@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=tyreld@linux.vnet.ibm.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 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.