From: Cornelia Huck <cohuck@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, "Michael S . Tsirkin" <mst@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>,
Greg Kurz <groug@kaod.org>, Igor Mammedov <imammedo@redhat.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-s390x@nongnu.org, Richard Henderson <rth@twiddle.net>,
Collin Walling <walling@linux.ibm.com>,
Thomas Huth <thuth@redhat.com>,
qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC] qdev: Let the hotplug_unplug() caller delete the device
Date: Mon, 3 Dec 2018 17:01:27 +0100 [thread overview]
Message-ID: <20181203170127.349625de.cohuck@redhat.com> (raw)
In-Reply-To: <20181128145455.11733-1-david@redhat.com>
On Wed, 28 Nov 2018 15:54:55 +0100
David Hildenbrand <david@redhat.com> wrote:
> When unplugging a device, at one point the device will be destroyed
> via object_unparent(). This will, one the one hand, unrealize the
> device hierarchy to be removed, and on the other hand, destroy/free the
> device hierarchy.
>
> When chaining interrupt handlers, we want to overwrite a bus hotplug
s/interrupt/hotplug/, no?
> handler by the machine hotplug handler, to be able to perform
> some part of the plug/unplug and to forward the calls to the bus hotplug
> handler.
>
> For now, the bus hotplug handler would trigger an object_unparent(), not
> allowing us to perform some unplug action on a device after we forwarded
> the call to the bus hotplug handler. The device would be gone at that
> point.
>
> hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
> machine_unplug_handler(dev) {
> /* eventually do unplug stuff */
> bus_unplug_handler(dev) -> calls object_unparent(dev)
> /* dev is gone, we can't do more unplug stuff */
> }
>
> So move the object_unparent() to the original caller of the unplug. For
> now, keep the unrealize() at the original places of the
> object_unparent().
>
> hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
> machine_unplug_handler(dev) {
> /* eventually do unplug stuff */
> bus_unplug_handler(dev) -> calls unrealize(dev)
> /* we can do more unplug stuff but device already unrealized */
> }
> object_unparent(dev)
>
> In the long run, every unplug action should be factored out of the
> unrealize() function into the unplug handler (especially for PCI). Then
> we can get rid of the additonal unrealize() calls and object_unparent()
> will properly unrealize the device hierarchy after the device has been
> unplugged.
>
> hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
> machine_unplug_handler(dev) {
> /* eventually do unplug stuff */
> bus_unplug_handler(dev) -> only unplugs, does not unrealize
> /* we can do more unplug stuff */
> }
> object_unparent(dev) -> will unrealize
>
>
> The original approach was suggested by Igor Mammedov for the PCI
> part, but I extended it to all hotplug handlers. I consider this one
> step into the right direction.
From my limited overview of the hotplug infrastructure, this looks
reasonable.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>
> I might still be missing some cases, but I want to get some feedback first
> if this makes sense.
>
> This is based on the series:
> [PATCH v3 00/11] pci: hotplug handler reworks
>
> hw/acpi/cpu.c | 1 +
> hw/acpi/memory_hotplug.c | 1 +
> hw/acpi/pcihp.c | 3 ++-
> hw/core/qdev.c | 3 +--
> hw/i386/pc.c | 5 ++---
> hw/pci/pcie.c | 3 ++-
> hw/pci/shpc.c | 3 ++-
> hw/ppc/spapr.c | 4 ++--
> hw/ppc/spapr_pci.c | 3 ++-
> hw/s390x/css-bridge.c | 2 +-
> hw/s390x/s390-pci-bus.c | 12 ++++++++++--
> qdev-monitor.c | 9 +++++++--
> 12 files changed, 33 insertions(+), 16 deletions(-)
> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> index 9abd49a9dc..a84e80f6dd 100644
> --- a/hw/s390x/s390-pci-bus.c
> +++ b/hw/s390x/s390-pci-bus.c
> @@ -988,7 +988,11 @@ static void s390_pcihost_unplug(HotplugHandler *hotplug_dev, DeviceState *dev,
> pbdev->fh, pbdev->fid);
> bus = pci_get_bus(pci_dev);
> devfn = pci_dev->devfn;
> - object_unparent(OBJECT(pci_dev));
> + if (OBJECT(pci_dev) == OBJECT(dev)) {
> + object_property_set_bool(OBJECT(pci_dev), false, "realized", NULL);
> + } else {
> + object_unparent(OBJECT(pci_dev));
> + }
> s390_pci_msix_free(pbdev);
> s390_pci_iommu_free(s, bus, devfn);
> pbdev->pdev = NULL;
> @@ -997,7 +1001,11 @@ out:
> pbdev->fid = 0;
> QTAILQ_REMOVE(&s->zpci_devs, pbdev, link);
> g_hash_table_remove(s->zpci_table, &pbdev->idx);
> - object_unparent(OBJECT(pbdev));
> + if (OBJECT(pbdev) == OBJECT(dev)) {
> + object_property_set_bool(OBJECT(pbdev), false, "realized", NULL);
> + } else {
> + object_unparent(OBJECT(pbdev));
> + }
That's a bit... ugly. Not really your code, but the inherent ugliness
of the architecture it uncovers; we basically have two devices paired
with each other and we need to unplug them both, regardless on which of
the two unplug is called.
Maybe add a comment explaining it a bit?
It looks correct, though; but I haven't tested it :)
Nothing bad jumped out at me from the rest of your patch, either.
next prev parent reply other threads:[~2018-12-03 16:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-28 14:54 [Qemu-devel] [PATCH RFC] qdev: Let the hotplug_unplug() caller delete the device David Hildenbrand
2018-12-03 16:01 ` Cornelia Huck [this message]
2018-12-04 13:19 ` David Hildenbrand
2018-12-04 13:33 ` Igor Mammedov
2018-12-04 15:23 ` 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=20181203170127.349625de.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=groug@kaod.org \
--cc=imammedo@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
--cc=walling@linux.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.