All of lore.kernel.org
 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 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.