qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	groug@kaod.org, qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
	eblake@redhat.com, david@gibson.dropbear.id.au
Subject: Re: [PATCH v4 3/3] memory_hotplug.c: send DEVICE_UNPLUG_ERROR in acpi_memory_hotplug_write()
Date: Fri, 9 Jul 2021 15:38:38 +0200	[thread overview]
Message-ID: <20210709153838.75de8813@redhat.com> (raw)
In-Reply-To: <87sg0n685k.fsf@dusky.pond.sub.org>

On Fri, 09 Jul 2021 13:25:43 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Igor Mammedov <imammedo@redhat.com> writes:
> 
> > On Thu, 08 Jul 2021 15:08:57 +0200
> > Markus Armbruster <armbru@redhat.com> wrote:
> >  
> >> Daniel Henrique Barboza <danielhb413@gmail.com> writes:
> >>   
> >> > MEM_UNPLUG_ERROR is deprecated since the introduction of
> >> > DEVICE_UNPLUG_ERROR. Keep emitting both while the deprecation of
> >> > MEM_UNPLUG_ERROR is pending.
> >> >
> >> > CC: Michael S. Tsirkin <mst@redhat.com>
> >> > CC: Igor Mammedov <imammedo@redhat.com>
> >> > Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> >> > Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> >> > ---
> >> >  hw/acpi/memory_hotplug.c | 13 +++++++++++--
> >> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
> >> > index af37889423..fb9f4d2de7 100644
> >> > --- a/hw/acpi/memory_hotplug.c
> >> > +++ b/hw/acpi/memory_hotplug.c
> >> > @@ -8,6 +8,7 @@
> >> >  #include "qapi/error.h"
> >> >  #include "qapi/qapi-events-acpi.h"
> >> >  #include "qapi/qapi-events-machine.h"
> >> > +#include "qapi/qapi-events-qdev.h"
> >> >  
> >> >  #define MEMORY_SLOTS_NUMBER          "MDNR"
> >> >  #define MEMORY_HOTPLUG_IO_REGION     "HPMR"
> >> > @@ -177,9 +178,17 @@ static void acpi_memory_hotplug_write(void *opaque, hwaddr addr, uint64_t data,
> >> >              /* call pc-dimm unplug cb */
> >> >              hotplug_handler_unplug(hotplug_ctrl, dev, &local_err);
> >> >              if (local_err) {
> >> > +                const char *error_pretty = error_get_pretty(local_err);
> >> > +
> >> >                  trace_mhp_acpi_pc_dimm_delete_failed(mem_st->selector);
> >> > -                qapi_event_send_mem_unplug_error(dev->id,
> >> > -                                                 error_get_pretty(local_err));
> >> > +
> >> > +                /*
> >> > +                 * Send both MEM_UNPLUG_ERROR and DEVICE_UNPLUG_ERROR
> >> > +                 * while the deprecation of MEM_UNPLUG_ERROR is
> >> > +                 * pending.
> >> > +                 */
> >> > +                qapi_event_send_mem_unplug_error(dev->id, error_pretty);
> >> > +                qapi_event_send_device_unplug_error(dev->id, error_pretty);
> >> >                  error_free(local_err);
> >> >                  break;
> >> >              }    
> >> 
> >> Same question as for PATCH 2: can dev->id be null?  
> > only theoretically (if memory device were created directly without
> > using device_add), which as far as I know is not the case as all
> > memory devices are created using -device/device_add so far.
> >
> > ( for device_add case see qdev_device_add->qdev_set_id where
> >   'id' is set to user provided or to generated "device[%d]" value)  
> 
> Something is set to a generated value, but it's not dev->id :)
> 
>     void qdev_set_id(DeviceState *dev, const char *id)
> 
> @id is the value of id=...  It may be null.
> 
> dev->id still is null here.
> 
>     {
>         if (id) {
>             dev->id = id;
>         }
> 
> dev->id is now the value of id=...  It may be null.
> 
>         if (dev->id) {
>             object_property_add_child(qdev_get_peripheral(), dev->id,
>                                       OBJECT(dev));
> 
> If the user specified id=..., add @dev as child of /peripheral.  The
> child's name is the (non-null) value of id=...
> 
>         } else {
>             static int anon_count;
>             gchar *name = g_strdup_printf("device[%d]", anon_count++);
>             object_property_add_child(qdev_get_peripheral_anon(), name,
>                                       OBJECT(dev));
>             g_free(name);
> 
> Else, add @dev as child of /peripheral-anon.  The child's name is made
> up.
> 
> 
>         }
>     }
> 
> dev->id is still the value of id=..., i.e. it may be null.
yep, I was wrong and confused it child name in QOM tree.

> Sure dereferencing dev->id in acpi_memory_hotplug_write() is safe?

it aren't safe since guest may trigger this error when
memory-device is created without id.



  reply	other threads:[~2021-07-09 13:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07  0:33 [PATCH v4 0/3] DEVICE_UNPLUG_ERROR QAPI event Daniel Henrique Barboza
2021-07-07  0:33 ` [PATCH v4 1/3] qapi/qdev.json: add " Daniel Henrique Barboza
2021-07-07  9:26   ` Greg Kurz
2021-07-08 13:01   ` Markus Armbruster
2021-07-08 14:20     ` Daniel Henrique Barboza
2021-07-12  2:26     ` David Gibson
2021-07-07  0:33 ` [PATCH v4 2/3] spapr: use DEVICE_UNPLUG_ERROR to report unplug errors Daniel Henrique Barboza
2021-07-07  9:28   ` Greg Kurz
2021-07-08 13:08   ` Markus Armbruster
2021-07-07  0:33 ` [PATCH v4 3/3] memory_hotplug.c: send DEVICE_UNPLUG_ERROR in acpi_memory_hotplug_write() Daniel Henrique Barboza
2021-07-07  9:28   ` Greg Kurz
2021-07-08 13:08   ` Markus Armbruster
2021-07-09  8:39     ` Igor Mammedov
2021-07-09 11:25       ` Markus Armbruster
2021-07-09 13:38         ` Igor Mammedov [this message]
2021-07-10  6:57           ` Markus Armbruster
2021-07-11  8:49             ` Daniel Henrique Barboza
2021-07-08  0:49 ` [PATCH v4 0/3] DEVICE_UNPLUG_ERROR QAPI event 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=20210709153838.75de8813@redhat.com \
    --to=imammedo@redhat.com \
    --cc=armbru@redhat.com \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=eblake@redhat.com \
    --cc=groug@kaod.org \
    --cc=mst@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 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).