From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: qemu-s390x@nongnu.org, qemu-ppc@nongnu.org,
Richard Henderson <rth@twiddle.net>,
David Gibson <david@gibson.dropbear.id.au>,
Laurent Vivier <lvivier@redhat.com>,
Cornelia Huck <cohuck@redhat.com>,
Collin Walling <walling@linux.ibm.com>,
Pierre Morel <pmorel@linux.ibm.com>,
Michael Roth <mdroth@linux.vnet.ibm.com>,
Halil Pasic <pasic@linux.ibm.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Greg Kurz <groug@kaod.org>, Igor Mammedov <imammedo@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Eric Auger <eric.auger@redhat.com>,
Pankaj Gupta <pagupta@redhat.com>,
David Hildenbrand <david@redhat.com>
Subject: [Qemu-devel] [PATCH v2 0/3] qdev: Hotplug handler chaining
Date: Thu, 28 Feb 2019 13:28:46 +0100 [thread overview]
Message-ID: <20190228122849.4296-1-david@redhat.com> (raw)
Can somebody please pick this up in the near future? (@Eduardo, @MST,
@Paolo, @David - I have no idea who the right person is :) )
The longer we wait, the more likely it is that some stuff gets upstreamed
that conflicts with patch 1 and will break unnoticed. (e.g. spapr PHB
hotplug was just upstreamed and required a fixup, luckily I was CC'ed on
that one).
---
This series implements support for hotplug handler chaining (proposed
by Igor), something that is necessary to turn selected virtio devices into
memory devices. Planned devices inlude virtio-mem and virtio-pmem.
The machine hotplug handler can intercept hotplug handler calls
to properly prepare/teardown the memory device part of a device. Control
is then passed on to the actual bus hotplug handler. So the default hotplug
handler is effectively overwritten to make interception possible.
This series was tested against the - now upstream - device unplug tests
part of "tests/device-plug-test".
v1 -> v2:
- Fixed spapr PHB unplug which was just upstreamed
RFCv2 -> v1:
- "qdev: Let the hotplug_handler_unplug() caller delete the device"
-- Fixed two spapr delete_device() calls I missed. Covered by tests now
-- Handle + add a comment for host pci bridge unplug, for which we have
code but no user yet.
- virtio-pmem prototype will be handled from this point by Pankaj again,
so no longer included
David Hildenbrand (2):
qdev: Let the hotplug_handler_unplug() caller delete the device
qdev: Provide qdev_get_bus_hotplug_handler()
Igor Mammedov (1):
qdev: Let machine hotplug handler to override bus hotplug handler
hw/acpi/cpu.c | 1 +
hw/acpi/memory_hotplug.c | 1 +
hw/acpi/pcihp.c | 3 ++-
hw/core/qdev.c | 19 ++++++++++++-------
hw/i386/pc.c | 5 ++---
hw/pci/pci.c | 3 ++-
hw/pci/pcie.c | 3 ++-
hw/pci/shpc.c | 3 ++-
hw/ppc/spapr.c | 9 ++++++---
hw/ppc/spapr_pci.c | 3 ++-
hw/s390x/css-bridge.c | 2 +-
hw/s390x/s390-pci-bus.c | 13 ++++++++-----
include/hw/qdev-core.h | 12 ++++++++++++
qdev-monitor.c | 9 +++++++--
14 files changed, 60 insertions(+), 26 deletions(-)
--
2.17.2
next reply other threads:[~2019-02-28 12:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 12:28 David Hildenbrand [this message]
2019-02-28 12:28 ` [Qemu-devel] [PATCH v2 1/3] qdev: Let the hotplug_handler_unplug() caller delete the device David Hildenbrand
2019-02-28 13:46 ` Greg Kurz
2019-02-28 12:28 ` [Qemu-devel] [PATCH v2 2/3] qdev: Let machine hotplug handler to override bus hotplug handler David Hildenbrand
2019-02-28 12:28 ` [Qemu-devel] [PATCH v2 3/3] qdev: Provide qdev_get_bus_hotplug_handler() David Hildenbrand
2019-02-28 17:17 ` [Qemu-devel] [PATCH v2 0/3] qdev: Hotplug handler chaining Eduardo Habkost
2019-03-01 16:08 ` [Qemu-devel] [qemu-s390x] " 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=20190228122849.4296-1-david@redhat.com \
--to=david@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=eric.auger@redhat.com \
--cc=groug@kaod.org \
--cc=imammedo@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mst@redhat.com \
--cc=pagupta@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--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 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).