qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

             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).