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
next prev parent 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).