From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: aik@ozlabs.ru, agraf@suse.de, ncmike@ncultra.org,
paulus@samba.org, tyreld@linux.vnet.ibm.com,
nfont@linux.vnet.ibm.com, qemu-ppc@nongnu.org
Subject: [Qemu-devel] [PATCH v2 00/14] spapr: add support for pci hotplug
Date: Thu, 5 Dec 2013 16:32:51 -0600 [thread overview]
Message-ID: <1386282785-466-1-git-send-email-mdroth@linux.vnet.ibm.com> (raw)
These patches are based on ppc-next, and can also be obtained from:
https://github.com/mdroth/qemu/commits/spapr-pci-hotplug-v2-ppc-next
v2:
* re-ordered patches to fix build bisectability (Alexey)
* replaced g_warning with DPRINTF in RTAS calls for guest errors (Alexey)
* replaced g_warning with fprintf for qemu errors (Alexey)
* updated RTAS calls to use pre-existing error/success macros (Alexey)
* replaced DR_*/SENSOR_* macros with INDICATOR_* for set-indicator/
get-sensor-state (Alexey)
OVERVIEW
These patches add support for PCI hotplug for SPAPR guests. We advertise
each PHB as DR-capable (as defined by PAPR 13.5/13.6) with 32 hotpluggable
PCI slots per PHB, which models a standard PCI expansion device for Power
machines where the DRC name/loc-code/index for each slot are generated
based on bus/slot number.
This is compatible with existing guest kernel's via the rpaphp hotplug
module, and existing userspace tools such as drmgr/librtas/rtas_errd for
managing devices, in theory...
NOTES / ADDITIONAL DEPENDENCIES
Due to an issue with rpaphp, a workaround must be used for older guest
kernels which relies on using bus rescan / remove sysfs interfaces instead
of rpaphp-provided hotplug interfaces.
Guest kernel fixes for rpaphp are in progress and available for testing
here (there's still currently a benign issue with duplicate eeh sysfs
entries with these, but the full guest-driven hotplug workflow is
functional):
https://github.com/mdroth/linux/commits/pci-hotplug-fixes
Alternatively, there are updated userspace tools which add a "-v" option
to drmgr to utilize bus rescan/remove instead of relying on rpaphp:
https://github.com/tyreld/powerpc-utils/commits/hotplug
It's possible to test guest-driven hotplug without either of these using
a workaround (see USAGE below), but not recommended.
PAPR does not currently define a mechanism for generating PCI
hotplug/unplug events, and relies on guest-driven management of devices,
so as part of this series we also introduce an extension to the existing
EPOW power event reporting mechanism (where a guest will query for events
via check-exception RTAS calls in response to an external interrupt) to
surface hotplug/unplug events with the information needed to manage the
devices automatically via the rtas_errd guest service. In order to enable
this qemu-driven hotplug/unplug workflow (for parity with ACPI/SHPC-based
guests), updated versions of librtas/ppc64-diag are required, which are
available here:
https://github.com/tyreld/ppc64-diag/commits/hotplug
https://github.com/tyreld/librtas/commits/hotplug
Lacking those, users must manage device hotplug/unplug manually.
Additionally, PAPR requires the presence of additional OF properties
(ibm,my-drc-index and loc-code) for hotpluggable slots that have already
been populated at the time of boot to support unplug, so an updated SLOF
is required to allow for device unplug after a guest reboot. (these
properties cannot currently be added to boot-time FDT, since they will
conflict with SLOF-generated device nodes, so we either need to teach
SLOF to re-use/merge existing entries, or simply have it generate the
required properties values for board-qemu, which is the approach taken
here). A patch for SLOF is available below, along with a pre-built
SLOF binary which includes it (for testing):
https://github.com/mdroth/SLOF/commit/2e09a2950db0ce8ed464b80cccfea56dccf85d66
https://github.com/mdroth/qemu/blob/19a390e3270a7defc7158ce29e52ff2b27d666ae/pc-bios/slof.bin
PATCH LAYOUT
Patches
1-3 advertise PHBs and associated slots as hotpluggable to guests
4-7 add RTAS interfaces required for device configuration
8-10 add helpers and potential fix to deal with QEMU-managed BAR
assignments
11 enables device_add/device_del for spapr machines and
guest-driven hotplug
12-14 define hotplug event structure and emit them in response to
device_add/device_del
USAGE
With unmodified guests:
hotplug:
qemu:
device_add e1000,id=slot0
guest:
drmgr -c pci -s "Slot 0" -n -a
echo 1 >/sys/bus/pci/rescan
unplug:
guest:
drmgr -c pci -s "Slot 0" -n -r
echo 1 >/sys/bus/pci/devices/0000:00:00.0/remove
qemu:
device_del slot0
With only updated guest kernel:
hotplug:
qemu:
device_add e1000,id=slot0
guest:
modprobe rpaphp
drmgr -c pci -s "Slot 0" -n -a
unplug:
guest:
drmgr -c pci -s "Slot 0" -n -r
qemu:
device_del slot0
With only updated powerpc-utils/drmgr:
hotplug:
qemu:
device_add e1000,id=slot0
guest:
drmgr -c pci -s "Slot 0" -n -v -a
unplug:
guest:
drmgr -c pci -s "Slot 0" -n -v -r
qemu:
device_del slot0
With updated librtas/ppc64-diag and either an updated guest kernel or drmgr:
hotplug:
qemu:
device_add e1000,id=slot0
unplug:
qemu:
device_del slot0
hw/pci/pci.c | 5 +-
hw/ppc/spapr.c | 174 +++++++++-
hw/ppc/spapr_events.c | 228 ++++++++++---
hw/ppc/spapr_pci.c | 768 ++++++++++++++++++++++++++++++++++++++++++-
include/exec/memory.h | 34 ++
include/hw/pci-host/spapr.h | 1 +
include/hw/pci/pci.h | 1 +
include/hw/ppc/spapr.h | 77 ++++-
memory.c | 50 +++
9 files changed, 1286 insertions(+), 52 deletions(-)
pickGIT: [PATCH v2 06/14] spapr_pci: add get-sensor-state RTAS interface
next reply other threads:[~2013-12-05 22:33 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-05 22:32 Michael Roth [this message]
2013-12-05 22:32 ` [Qemu-devel] [PATCH v2 01/14] spapr: populate DRC entries for root dt node Michael Roth
2013-12-16 2:59 ` Alexey Kardashevskiy
2013-12-16 4:54 ` Alexey Kardashevskiy
2014-01-16 20:51 ` Michael Roth
2014-01-20 2:58 ` Alexey Kardashevskiy
2014-01-20 14:12 ` Mike Day
2014-01-20 17:24 ` Michael Roth
2014-01-20 17:59 ` Mike Day
2014-01-20 18:51 ` Michael Roth
2013-12-05 22:32 ` [Qemu-devel] [PATCH v2 02/14] spapr_pci: populate DRC dt entries for PHBs Michael Roth
2013-12-05 22:32 ` [Qemu-devel] [PATCH v2 03/14] spapr: add helper to retrieve a PHB/device DrcEntry Michael Roth
2013-12-05 22:32 ` [Qemu-devel] [PATCH v2 04/14] spapr_pci: add set-indicator RTAS interface Michael Roth
2013-12-16 4:26 ` Alexey Kardashevskiy
2014-01-16 20:54 ` Michael Roth
2013-12-05 22:32 ` [Qemu-devel] [PATCH v2 05/14] spapr_pci: add get/set-power-level RTAS interfaces Michael Roth
2013-12-16 3:09 ` Alexey Kardashevskiy
2014-01-16 21:01 ` Michael Roth
2013-12-05 22:32 ` [Qemu-devel] [PATCH v2 06/14] spapr_pci: add get-sensor-state RTAS interface Michael Roth
2013-12-05 22:32 ` [Qemu-devel] [PATCH v2 07/14] spapr_pci: add ibm, configure-connector " Michael Roth
2013-12-05 22:32 ` [Qemu-devel] [PATCH v2 08/14] memory: add memory_region_find_subregion Michael Roth
2013-12-05 22:33 ` [Qemu-devel] [PATCH v2 09/14] pci: make pci_bar useable outside pci.c Michael Roth
2013-12-05 22:33 ` [Qemu-devel] [PATCH v2 10/14] pci: allow 0 address for PCI IO regions Michael Roth
2013-12-05 23:33 ` Peter Maydell
2013-12-10 21:42 ` Michael Roth
2013-12-10 22:14 ` Peter Maydell
2013-12-10 23:03 ` [Qemu-devel] [Qemu-ppc] " Benjamin Herrenschmidt
2013-12-12 14:34 ` [Qemu-devel] " Michael S. Tsirkin
2013-12-05 22:33 ` [Qemu-devel] [PATCH v2 11/14] spapr_pci: enable basic hotplug operations Michael Roth
2013-12-16 4:36 ` Alexey Kardashevskiy
2014-01-16 21:22 ` Michael Roth
2013-12-05 22:33 ` [Qemu-devel] [PATCH v2 12/14] spapr_events: re-use EPOW event infrastructure for hotplug events Michael Roth
2013-12-16 5:05 ` Alexey Kardashevskiy
2014-01-16 21:32 ` Michael Roth
2013-12-05 22:33 ` [Qemu-devel] [PATCH v2 13/14] spapr_events: event-scan RTAS interface Michael Roth
2013-12-16 4:57 ` Alexey Kardashevskiy
2013-12-05 22:33 ` [Qemu-devel] [PATCH v2 14/14] spapr_pci: emit hotplug add/remove events during hotplug Michael Roth
2013-12-16 5:06 ` Alexey Kardashevskiy
2014-01-10 8:29 ` [Qemu-devel] [PATCH v2 00/14] spapr: add support for pci hotplug Alexey Kardashevskiy
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=1386282785-466-1-git-send-email-mdroth@linux.vnet.ibm.com \
--to=mdroth@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=ncmike@ncultra.org \
--cc=nfont@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=tyreld@linux.vnet.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).