[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 4/5] spapr: Pass &error_abort when getting some PC DIMM prope
From: |
Igor Mammedov |
Subject: |
Re: [PATCH 4/5] spapr: Pass &error_abort when getting some PC DIMM properties |
Date: |
Wed, 28 Oct 2020 16:22:16 +0100 |
On Tue, 27 Oct 2020 16:18:58 +0100
Greg Kurz <groug@kaod.org> wrote:
> On Tue, 27 Oct 2020 12:54:24 +0100
> Igor Mammedov <imammedo@redhat.com> wrote:
>
> > On Sun, 25 Oct 2020 16:24:44 +0100
> > Greg Kurz <groug@kaod.org> wrote:
> >
> > > On Fri, 23 Oct 2020 21:15:09 +0200
> > > Igor Mammedov <imammedo@redhat.com> wrote:
> > >
> > > > On Mon, 19 Oct 2020 10:48:41 +0200
> > > > Greg Kurz <groug@kaod.org> wrote:
> > > >
> > > > > Both PC_DIMM_SLOT_PROP and PC_DIMM_ADDR_PROP are defined in the
> > > > > default property list of the PC DIMM device class:
> > > > >
> > > > > DEFINE_PROP_UINT64(PC_DIMM_ADDR_PROP, PCDIMMDevice, addr, 0),
> > > > >
> > > > > DEFINE_PROP_INT32(PC_DIMM_SLOT_PROP, PCDIMMDevice, slot,
> > > > > PC_DIMM_UNASSIGNED_SLOT),
> > > > >
> > > > > They should thus be always gettable for both PC DIMMs and NVDIMMs.
> > > > > An error in getting them can only be the result of a programming
> > > > > error. It doesn't make much sense to propagate the error in this
> > > > > case. Abort instead.
> > > > >
> > > > > Signed-off-by: Greg Kurz <groug@kaod.org>
> > > >
> > > > Reviewed-by: Igor Mammedov <imammedo@redhat.com>
> > > >
> > > > TODO for future,
> > > > get rid of local_err in spapr_memory_plug() altogether, it should not
> > > > fail.
> > > > it needs moving check from spapr_drc_attach() to
> > > > spapr_memory_pre_plug() time.
> > > >
> > > > that will clear up (a bit) road for dropping errp in
> > > > spapr_memory_plug()
> > >
> > > Igor,
> > >
> > > I could find time to look a bit into attaching DRCs at pre-plug and I
> > > think this isn't possible. The problem is that there doesn't seem to be
> > > a reverse operation for pre-plug. If realize fails for the DIMM device,
> > > spapr_drc_detach() wouldn't be called, which would be wrong.
> >
> > probably I was clear enough, I didn't suggest to move spapr_drc_detach()
> > to pre_plug time but rather do a bit of surgery along the lines:
> >
>
> Ok, I get it now. I realize now I actually misread your suggestion. Sorry...
>
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 2db810f73a..59a229b4fa 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -3474,6 +3474,11 @@ static void spapr_memory_pre_plug(HotplugHandler
> > *hotplug_dev, DeviceState *dev,
> > return;
> > }
> >
> > + get drc
> > + if (!spapr_drc_attachable(drc)) {
> > + error out
> > + }
> > +
>
> It might require some more code refactoring because the way regular
> PC-DIMMs are broken down into a set of logical memory blocks (LMBs),
> each one having its own DRC but it's certainly doable. Probably for
> QEMU 6.0 though since we're entering soft freeze and David already
> fired a PR today.
as far as it's not forgotten, it can be done later.
>
> > if (is_nvdimm) {
> > spapr_nvdimm_validate(hotplug_dev, NVDIMM(dev), size, &local_err);
> > if (local_err) {
> > diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
> > index fe998d8108..ae049bc202 100644
> > --- a/hw/ppc/spapr_drc.c
> > +++ b/hw/ppc/spapr_drc.c
> > @@ -371,14 +371,16 @@ static void prop_get_fdt(Object *obj, Visitor *v,
> > const char *name,
> > } while (fdt_depth != 0);
> > }
> >
> > -void spapr_drc_attach(SpaprDrc *drc, DeviceState *d, Error **errp)
> > +
> > +bool spapr_drc_attachable(SpaprDrc *drc)
> > +{
> > + return !drc->dev;
> > +}
> > +
> > +void spapr_drc_attach(SpaprDrc *drc, DeviceState *d)
> > {
> > trace_spapr_drc_attach(spapr_drc_index(drc));
> >
> > - if (drc->dev) {
> > - error_setg(errp, "an attached device is still awaiting release");
> > - return;
> > - }
> > g_assert((drc->state == SPAPR_DRC_STATE_LOGICAL_UNUSABLE)
> > || (drc->state == SPAPR_DRC_STATE_PHYSICAL_POWERON));
> >
> > >
> > > Am I missing something ?
[...]
- Re: [PATCH 2/5] spapr: Use appropriate getter for PC_DIMM_ADDR_PROP, (continued)
[PATCH 5/5] spapr: Simplify error handling in spapr_memory_plug(), Greg Kurz, 2020/10/19
Re: [PATCH 0/5] spapr: Error handling fixes and cleanups (round 3), David Gibson, 2020/10/22