pci: make pci_bar useable outside pci.c

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
spapr_pci: enable basic hotplug operations

This enables hotplug for PHB bridges. Upon hotplug we generate the
OF-nodes required by PAPR specification and IEEE 1275-1994
"PCI Bus Binding to Open Firmware" for the device.

We associate the corresponding FDT for these nodes with the DrcEntry
corresponding to the slot, which will be fetched via
ibm,configure-connector RTAS calls by the guest as described by PAPR
specification. The FDT is cleaned up in the case of unplug.

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
spapr_events: re-use EPOW event infrastructure for hotplug events

This extends the data structures currently used to report EPOW events to
gets via the check-exception RTAS interfaces to also include event types
for hotplug/unplug events.

This is currently undocumented and being finalized for inclusion in PAPR
specification, but we implement this here as an extension for guest
userspace tools to implement (existing guest kernels simply log these
events via a sysfs interface that's read by rtas_errd).

Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
spapr_events: event-scan RTAS interface

We don't actually rely on this interface to surface hotplug events, and
instead rely on the similar-but-interrupt-driven check-exception RTAS
interface used for EPOW events. However, the existence of this interface
is needed to ensure guest kernels initialize the event-reporting
interfaces which will in turn be used by userspace tools to handle these
events, so we implement this interface as a stub.

Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
spapr_pci: emit hotplug add/remove events during hotplug

This uses extension of existing EPOW interrupt/event mechanism
to notify userspace tools like librtas/drmgr to handle
in-guest configuration/cleanup operations in response to
device_add/device_del.

Userspace tools that don't implement this extension will need
to be run manually in response/advance of device_add/device_del,
respectively.

Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
memory: add memory_region_find_subregion

Similar to memory_region_find, but only search for overlaps among
regions that are a child of the region passed in. This is useful
for finding free ranges within a parent range to map to, in
addition to the use-cases similarly served by memory_region_find.

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
machine: add managed-hotplug option

For some platforms, pSeries in this case, we have the option of having
firmware handle initial device setup (such as BAR mappings), which is
described to the guest OS via OF device tree properties and processed
by the rpaphp hotplug module in the linux kernel.

Due to a long-standing issue with past guest kernels, rpaphp is not
useable for cases where we have more than one hotpluggable slot
associated with a PHB without a patched guest kernel, which is the
case with QEMU guests.

To support older guests, we currently make use of the drmgr userspace
daemon to discover hotplugged devices using the generic PCI rescan code
exposed via sysfs, which does not rely on these OF properties and
instead relies on the guest kernel to handle setup and BAR assignments.

Going forward, to re-enable firmware-assigned setup for use in
conjunction with patched guest kernels, we introduce this machine
option, which will be used by QEMU to determine whether it should
emulate firmware-based device setup and signal this using a new hotplug
event type, both of which will be introduced in the following patches.

This is currently pseries-specific, but may be applicable to other
platforms as well, so we don't do anything special to restrict the
option to pseries.

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
spapr_events: add managed pci hotplug event type

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
spapr_pci: enable firmware-assigned device configuration

On pSeries guests, the rpaphp hotplug kernel module expects the
firmware to handle BAR assignments. Due to other issues, this
module will not work for unpatched guest kernels, so the previous
implementation of hotplug did not rely on this functionality, and
instead used the generic sysfs-based rescan infrastructure to
handle these assignments.

This works, but it is not ideal since it does not tie into the
established kernel interfaces for handling hotplug, and there
maybe exist devices where firmware-based assignments are needed.
With the managed-hotplug -machine option introduced earlier, we can
now selectively enable this approach by emulating firmware-based
assignments through QEMU prior to advertising the device to the
guest when managed-hotplug=on.

Amongst the required OF-node properties for each device are the "reg"
and "assigned-addresses" properties which describe the BAR-assignments
for IO/MEM/ROM regions. To handle these assignments we scan the address
space associated with each region for a contiguous range of appropriate
size based on PCI specification and encode these in accordance with
Open Firmware PCI Bus Binding spec. These assignments will be used by
the guest when the rpaphp hotplug module is used.

Signed-off-by: Mike Day <ncmike@ncultra.org>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
*spapr_pci: hotplug, only do bar-assignment when managed-hotplug=on

When managed-hotplug=off, we expect the guest OS to handle the
assignments.

(this should be squashed into bar-assignment patch)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>