aboutsummaryrefslogtreecommitdiff
path: root/include/hw/ppc/spapr_drc.h
AgeCommit message (Collapse)Author
2016-07-12Clean up ill-advised or unusual header guardsMarkus Armbruster
Cleaned up with scripts/clean-header-guards.pl. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
2016-07-12Use #include "..." for our own headers, <...> for othersMarkus Armbruster
Tracked down with an ugly, brittle and probably buggy Perl script. Also move includes converted to <...> up so they get included before ours where that's obviously okay. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Eric Blake <eblake@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
2016-06-17spapr_drc: Prevent detach racing against attach for CPU DRBharata B Rao
If a CPU is hot removed while hotplug of the same is still in progress, the guest crashes. Prevent this by ensuring that detach is done only after attach has completed. The existing code already prevents such race for PCI hotplug. However given that CPU is a logical DR unlike PCI and starts with ISOLATED state, we need a logic that works for CPU too. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> [Don't set awaiting_attach for PCI devices] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-04-05spapr_drc: enable immediate detach for unsignalled devicesMichael Roth
Currently spapr doesn't support "aborting" hotplug of PCI devices by allowing device_del to immediately remove the device if we haven't signalled the presence of the device to the guest. In the past this wasn't an issue, since we always immediately signalled device attach and simply relied on full guest-aware add->remove path for device removal. However, as of 788d259, we now defer signalling for PCI functions until function 0 is attached, so now we need to deal with these "abort" operations for cases where a user hotplugs a non-0 function, then opts to remove it prior hotplugging function 0. Currently they'd have to reboot before the unplug completed. PCIe multifunction hotplug does not have this requirement however, so from a management implementation perspective it would be good to address this within the same release as 788d259. We accomplish this by simply adding a 'signalled' flag to track whether a device hotplug event has been sent to the guest. If it hasn't, we allow immediate removal under the assumption that the guest will not be using the device. Devices present at boot/reset time are also assumed to be 'signalled'. For CPU/memory/etc, signalling will still happen immediately as part of device_add, so only PCI functions should be affected. Cc: bharata@linux.vnet.ibm.com Cc: david@gibson.dropbear.id.au Cc: sbhat@linux.vnet.ibm.com Cc: qemu-ppc@nongnu.org Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> [dwg: This fixes a regression where an incorrect hot-add of a non-zero function can no longer be backed out until function 0 is added] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-23spapr_drc: use RTAS return codes for methods called by RTASMichael Roth
Certain methods in sPAPRDRConnector objects are only ever called by RTAS and in many cases are responsible for the logic that determines the RTAS return codes. Rather than having a level of indirection requiring RTAS code to re-interpret return values from such methods to determine the appropriate return code, just pass them through directly. This requires changing method return types to uint32_t to match the type of values currently passed to RTAS helpers. In the case of read accesses like drc->entity_sense() where we weren't previously reporting any errors, just the read value, we modify the function to return RTAS return code, and pass the read value back via reference. Suggested-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Suggested-by: David Gibson <david@gibson.dropbear.id.au> Cc: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-09-23spapr_rtas: Prevent QEMU crash during hotplug without a prior device_addBharata B Rao
If drmgr is used in the guest to hotplug a device before a device_add has been issued via the QEMU monitor, QEMU segfaults in configure_connector call. This occurs due to accessing of NULL FDT which otherwise would have been created and associated with the DRC during device_add command. Check for NULL FDT and return failure from configure_connector call. As per PAPR+, an error value of -9003 seems appropriate for this failure. Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com> Cc: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2015-06-03spapr_drc: add spapr_drc_populate_dt()Michael Roth
This function handles generation of ibm,drc-* array device tree properties to describe DRC topology to guests. This will by used by the guest to direct RTAS calls to manage any dynamic resources we associate with a particular DR Connector as part of hotplug/unplug. Since general management of boot-time device trees are handled outside of sPAPRDRConnector, we insert these values blindly given an FDT and offset. A mask of sPAPRDRConnector types is given to instruct us on what types of connectors entries should be generated for, since descriptions for different connectors may live in different parts of the device tree. Based on code originally written by Nathan Fontenot. Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>
2015-06-03spapr_drc: initial implementation of sPAPRDRConnector deviceMichael Roth
This device emulates a firmware abstraction used by pSeries guests to manage hotplug/dynamic-reconfiguration of host-bridges, PCI devices, memory, and CPUs. It is conceptually similar to an SHPC device, complete with LED indicators to identify individual slots to physical physical users and indicate when it is safe to remove a device. In some cases it is also used to manage virtualized resources, such a memory, CPUs, and physical-host bridges, which in the case of pSeries guests are virtualized resources where the physical components are managed by the host. Guests communicate with these DR Connectors using RTAS calls, generally by addressing the unique DRC index associated with a particular connector for a particular resource. For introspection purposes we expose this state initially as QOM properties, and in subsequent patches will introduce the RTAS calls that make use of it. This constitutes to the 'guest' interface. On the QEMU side we provide an attach/detach interface to associate or cleanup a DeviceState with a particular sPAPRDRConnector in response to hotplug/unplug, respectively. This constitutes the 'physical' interface to the DR Connector. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>