Commits

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> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

This enables hotplug of PCI devices to a PHB. 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 DRC corresponding to the slot, which will be fetched via ibm,configure-connector RTAS calls by the guest as described by PAPR specification. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

We need to work with PCI BARs to generate OF properties during PCI hotplug for sPAPR guests. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Cc: mst@redhat.com

These will be used to support hotplug/unplug of PCI devices to the PCI bus associated with a particular PHB. We also set up device-tree properties in each PHBs initial FDT to describe the DRCs associated with them. This advertises to guests that each PHB is DR-capable device with physical hotpluggable slots, each managed by the corresponding DRC. This is necessary for allowing hotplugging of devices to it later via bus rescan or guest rpaphp hotplug module. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

This option enables/disables PCI hotplug for a particular PHB. Also add machine compatibility code to disable it by default for machine types prior to pseries-2.3. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

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>

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 here. Since events surfaced by this call are mutually exclusive to those surfaced via check-exception, we also update the RTAS event queue code to accept a boolean to mark/filter for events accordingly. Events of this sort are not currently generated by QEMU, but the interface has been tested by surfacing hotplug events via event-scan in place of check-exception. Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

This extends the data structures currently used to report EPOW events to guests 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, and current versions of rtas_errd/powerpc-utils already support the use of this mechanism for initiating hotplug operations). We also add support for queues of pending RTAS events, since in the case of hotplug there's chance for multiple events being in-flight at any point in time. 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>

This interface is used to fetch an OF device-tree nodes that describes a newly-attached device to guest. It is called multiple times to walk the device-tree node and fetch individual properties into a 'workarea'/buffer provided by the guest. The device-tree is generated by QEMU and passed to an sPAPRDRConnector during the initial hotplug operation, and the state of these RTAS calls is tracked by the sPAPRDRConnector. When the last of these properties is successfully fetched, we report as special return value to the guest and transition the device to a 'configured' state on the QEMU/DRC side. See docs/specs/ppc-spapr-hotplug.txt for a complete description of this interface. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>

This is similar to the existing rtas_st_buffer(), but for cases where the guest is not expecting a length-encoded byte array. Namely, for calls where a "work area" buffer is used to pass around arbitrary fields/data. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

This interface allows a guest to read various platform/device sensors. initially, we only implement support necessary to support hotplug: reading of the dr-entity-sense sensor, which communicates the state of a hotplugged resource/device to the guest (EMPTY/PRESENT/UNUSABLE). See docs/specs/ppc-spapr-hotplug.txt for a complete description of this interface. Signed-off-by: Mike Day <ncmike@ncultra.org> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

This interface allows a guest to control various platform/device sensors. Initially, we only implement support necessary to control sensors that are required for hotplug: DR connector indicators/LEDs, resource allocation state, and resource isolation state. See docs/specs/ppc-spapr-hotplug.txt for a complete description of this interface. Signed-off-by: Mike Day <ncmike@ncultra.org> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

These interfaces manage the power domains that guest devices are assigned to and are used to power on/off devices. Currently we only utilize 1 power domain, the 'live-insertion' domain, which automates power management of plugged/unplugged devices, essentially making these calls no-ops, but the RTAS interfaces are still required by guest hotplug code and PAPR+. See docs/specs/ppc-spapr-hotplug.txt for a complete description of these interfaces. 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>

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>

This adds a general overview of hotplug/dynamic-reconfiguration for sPAPR/pSeries guest. As specified in PAPR+ v2.7. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

The patch implements sPAPRPHBClass EEH callbacks so that the EEH RTAS requests can be routed to VFIO for further handling. Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>

The emulation for EEH RTAS requests from guest isn't covered by QEMU yet and the patch implements them. The patch defines constants used by EEH RTAS calls and adds callbacks sPAPRPHBClass::{eeh_set_option, eeh_get_state, eeh_reset, eeh_configure}, which are going to be used as follows: * RTAS calls are received in spapr_pci.c, sanity check is done there. * RTAS handlers handle what they can. If there is something it cannot handle and the corresponding sPAPRPHBClass callback is defined, it is called. * Those callbacks are only implemented for VFIO now. They do ioctl() to the IOMMU container fd to complete the calls. Error codes from that ioctl() are transferred back to the guest. [aik: defined RTAS tokens for EEH RTAS calls] Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>

5b79b1c "target-ppc: Create versionless CPU class per family if KVM" added a dynamic CPU class registration with the name of the CPU family which QEMU is running on. For example, this allowed specifying "-cpu POWER7" on every version of POWER7 machine, not just the one which POWER7 was an alias of. I.e. before 5b79b1c, "-cpu POWER7" would not work on real POWER7 2.1 and would work on POWER7 2.3 only. The same story for POWER8. However that patch broke POWER5+ support as POWER5+ CPU uses the same name as the CPU class so dynamic registering of the POWER5+ class failed. This redefines POWER5+ server CPUs by adding a version to them and adding an alias for TCG case. KVM will use dynamically registered CPUs. While we are here, do the same for 970 CPU. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Alexander Graf <agraf@suse.de>

This patch adds basic support for the VTB. PowerISA: The Virtual Time Base (VTB) is a 64-bit incrementing counter. Virtual Time Base increments at the same rate as the Time Base until its value becomes 0xFFFF_FFFF_FFFF_FFFF (2 64 - 1); at the next increment its value becomes 0x0000_0000_0000_0000. There is no interrupt or other indication when this occurs. The operation of the Virtual Time Base has the following additional properties. 1. Loading a GPR from the Virtual Time Base has no effect on the accuracy of the Virtual Time Base. 2. Copying the contents of a GPR to the Virtual Time Base replaces the contents of the Virtual Time Base with the contents of the GPR. Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com> Signed-off-by: Alexander Graf <agraf@suse.de>

The CONFIG_OPENPIC variable was declared multiple times. We only need it once. Signed-off-by: Alexander Graf <agraf@suse.de>

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>

This removes floppy disks support as it is not supported by any PPC64 system anyway as the only way to have floppy disk on such systems would be an ISA bus and Linux kernels seems have never had such support. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>

…hip used by prep" This reverts commit 9c99842 as even when it was applied, all supposedly new config options were already enabled. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Alexander Graf <agraf@suse.de>

Bonus fix: always set an error on failure. Some failures were silent before, except for the generic error set by device_realize(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alexander Graf <agraf@suse.de>

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Alexander Graf <agraf@suse.de> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Alexander Graf <agraf@suse.de>

This is in preparation for using VMSTATE_BITMAP in a followup vmstate migration patch. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Alexander Graf <agraf@suse.de>

Issuing loadvm under -M mac99 would fail for two reasons: firstly an incorrect version number for openpic would cause openpic_load() to abort, and secondly a cut/paste error when restoring the IVPR and IDR registers caused subsequent vmstate sections to become misaligned and abort early. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Alexander Graf <agraf@suse.de>

A simple copy/paste error causes savevm on -M mac99 to segfault. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Alexander Graf <agraf@suse.de>

Since env->msr has already been restored by the time cpu_post_load is called, make sure that ppc_store_msr() is explicitly called with all msr bits except MSR_TGPR marked as invalid. This solves the issue where MSR flags aren't set correctly when restoring a VM snapshot, in particular the internal env->excp_prefix value when MSR_EP has been altered by a guest. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Alexander Graf <agraf@suse.de>

…r1() Otherwise when cpu_post_load calls ppc_store_sdr1() when restoring a VM snapshot the value is deemed unchanged and so the internal env->htab* variables aren't set correctly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alexander Graf <agraf@suse.de>

Make sure that we include the adb_poll_timer when saving the VM state for client OSs that use it, e.g. Darwin. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Alexander Graf <agraf@suse.de>

The parent ADBDevice contains the device id on the ADB bus. Make sure that this state is included in both its subclasses since some clients (such as OpenBIOS) reprogram each device id after enumeration. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Alexander Graf <agraf@suse.de>

This ensures that the macio PCI device is correctly configured when restoring from a VM snapshot. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Alexander Graf <agraf@suse.de>

Signed-off-by: Fabien Chouteau <chouteau@adacore.com> Signed-off-by: Alexander Graf <agraf@suse.de>

Commits on Mar 4, 2015