qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, Pankaj Gupta <pagupta@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, qemu-ppc@nongnu.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 03/18] qdev: let machine hotplug handler to override bus hotplug handler
Date: Mon, 14 May 2018 21:00:17 -0300	[thread overview]
Message-ID: <20180515000017.GB12837@kermit-br-ibm-com> (raw)
In-Reply-To: <20180514100023.12542-4-david@redhat.com>

On Mon, May 14, 2018 at 12:00:08PM +0200, David Hildenbrand wrote:
> From: Igor Mammedov <imammedo@redhat.com>
> 
> it will allow to return another hotplug handler than the default
> one for a specific bus based device type. Which is needed to handle
> non trivial plug/unplug sequences that need the access to resources
> configured outside of bus where device is attached.
> 
> That will allow for returned hotplug handler to orchestrate wiring
> in arbitrary order, by chaining other hotplug handlers when
> it's needed.
> 
> PS:
> It could be used for hybrid virtio-mem and virtio-pmem devices
> where it will return machine as hotplug handler which will do
> necessary wiring at machine level and then pass control down
> the chain to bus specific hotplug handler.
> 
> Example of top level hotplug handler override and custom plug sequence:
> 
>   some_machine_get_hotplug_handler(machine){
>       if (object_dynamic_cast(OBJECT(dev), TYPE_SOME_BUS_DEVICE)) {
>           return HOTPLUG_HANDLER(machine);
>       }
>       return NULL;
>   }
> 
>   some_machine_device_plug(hotplug_dev, dev) {
>       if (object_dynamic_cast(OBJECT(dev), TYPE_SOME_BUS_DEVICE)) {
>           /* do machine specific initialization */
>           some_machine_init_special_device(dev)
> 
>           /* pass control to bus specific handler */
>           hotplug_handler_plug(dev->parent_bus->hotplug_handler, dev)
>       }
>   }

Hi, David.

I might be misreading, but isn't it more like the following?

    some_machine_device_plug(hotplug_dev, dev) {
        if (object_dynamic_cast(OBJECT(dev), TYPE_SOME_BUS_DEVICE)) {
            /* do machine specific initialization */
            some_machine_init_special_device(dev)
        } else {
            /* pass control to bus specific handler */
            hotplug_handler_plug(dev->parent_bus->hotplug_handler, dev)
        }
    }

> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  hw/core/qdev.c         |  6 ++----
>  include/hw/qdev-core.h | 11 +++++++++++
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> index f6f92473b8..885286f579 100644
> --- a/hw/core/qdev.c
> +++ b/hw/core/qdev.c
> @@ -261,12 +261,10 @@ HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev)
>  
>  HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
>  {
> -    HotplugHandler *hotplug_ctrl;
> +    HotplugHandler *hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
>  
> -    if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
> +    if (hotplug_ctrl == NULL && dev->parent_bus) {
>          hotplug_ctrl = dev->parent_bus->hotplug_handler;
> -    } else {
> -        hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
>      }
>      return hotplug_ctrl;
>  }
> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> index 9453588160..e6a8eca558 100644
> --- a/include/hw/qdev-core.h
> +++ b/include/hw/qdev-core.h
> @@ -286,6 +286,17 @@ void qdev_init_nofail(DeviceState *dev);
>  void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
>                                   int required_for_version);
>  HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev);
> +/**
> + * qdev_get_hotplug_handler: Get handler responsible for device wiring
> + *
> + * Find HOTPLUG_HANDLER for @dev that provides [pre|un]plug callbacks for it.
> + *
> + * Note: in case @dev has a parent bus, it will be returned as handler unless
> + * machine handler overrides it.
> + *
> + * Returns: pointer to object that implements TYPE_HOTPLUG_HANDLER interface
> + *          or NULL if there aren't any.
> + */
>  HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev);
>  void qdev_unplug(DeviceState *dev, Error **errp);
>  void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
> -- 
> 2.14.3
> 
> 

-- 
Murilo

  reply	other threads:[~2018-05-15  0:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-14 10:00 [Qemu-devel] [PATCH v3 00/18] MemoryDevice: use multi stage hotplug handlers David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 01/18] memory-device: drop assert related to align and start of address space David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 02/18] memory-device: introduce separate config option David Hildenbrand
2018-05-15  0:20   ` [Qemu-devel] [Qemu-ppc] " Murilo Opsfelder Araujo
2018-05-15 15:21     ` Eric Blake
2018-05-16  9:31       ` David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 03/18] qdev: let machine hotplug handler to override bus hotplug handler David Hildenbrand
2018-05-15  0:00   ` Murilo Opsfelder Araujo [this message]
2018-05-15  8:07     ` [Qemu-devel] [Qemu-ppc] " David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 04/18] pc: prepare for multi stage hotplug handlers David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 05/18] pc: route all memory devices through the machine hotplug handler David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 06/18] spapr: prepare for multi stage hotplug handlers David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 07/18] spapr: route all memory devices through the machine hotplug handler David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 08/18] spapr: handle pc-dimm unplug via hotplug handler chain David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 09/18] spapr: handle cpu core " David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 10/18] memory-device: new functions to handle plug/unplug David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 11/18] pc-dimm: implement new memory device functions David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 12/18] memory-device: factor out pre-plug into hotplug handler David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 13/18] memory-device: factor out unplug " David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 14/18] memory-device: factor out plug " David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 15/18] s390x/sclp: make sure ram_size and maxram_size stay in sync David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 16/18] s390x: prepare for multi stage hotplug handlers David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 17/18] s390x: initialize memory region for memory devices David Hildenbrand
2018-05-14 10:00 ` [Qemu-devel] [PATCH v3 18/18] s390x: support " David Hildenbrand
2018-05-14 10:38   ` David Hildenbrand

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=20180515000017.GB12837@kermit-br-ibm-com \
    --to=muriloo@linux.ibm.com \
    --cc=armbru@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pagupta@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    /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).