qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-ppc] [PATCH v2 00/14] spapr: add support for pci hotplug


From: Michael Roth
Subject: [Qemu-ppc] [PATCH v2 00/14] spapr: add support for pci hotplug
Date: Thu, 5 Dec 2013 16:32:51 -0600

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]