spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
/*
|
|
|
|
* QEMU SPAPR Dynamic Reconfiguration Connector Implementation
|
|
|
|
*
|
|
|
|
* Copyright IBM Corp. 2014
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
*/
|
2016-06-29 14:47:03 +03:00
|
|
|
|
|
|
|
#ifndef HW_SPAPR_DRC_H
|
|
|
|
#define HW_SPAPR_DRC_H
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
|
2016-06-22 20:11:19 +03:00
|
|
|
#include <libfdt.h>
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
#include "qom/object.h"
|
|
|
|
#include "hw/qdev.h"
|
|
|
|
|
|
|
|
#define TYPE_SPAPR_DR_CONNECTOR "spapr-dr-connector"
|
|
|
|
#define SPAPR_DR_CONNECTOR_GET_CLASS(obj) \
|
|
|
|
OBJECT_GET_CLASS(sPAPRDRConnectorClass, obj, TYPE_SPAPR_DR_CONNECTOR)
|
|
|
|
#define SPAPR_DR_CONNECTOR_CLASS(klass) \
|
|
|
|
OBJECT_CLASS_CHECK(sPAPRDRConnectorClass, klass, \
|
|
|
|
TYPE_SPAPR_DR_CONNECTOR)
|
|
|
|
#define SPAPR_DR_CONNECTOR(obj) OBJECT_CHECK(sPAPRDRConnector, (obj), \
|
|
|
|
TYPE_SPAPR_DR_CONNECTOR)
|
|
|
|
|
2017-06-04 13:25:17 +03:00
|
|
|
#define TYPE_SPAPR_DRC_PHYSICAL "spapr-drc-physical"
|
|
|
|
#define SPAPR_DRC_PHYSICAL_GET_CLASS(obj) \
|
|
|
|
OBJECT_GET_CLASS(sPAPRDRConnectorClass, obj, TYPE_SPAPR_DRC_PHYSICAL)
|
|
|
|
#define SPAPR_DRC_PHYSICAL_CLASS(klass) \
|
|
|
|
OBJECT_CLASS_CHECK(sPAPRDRConnectorClass, klass, \
|
|
|
|
TYPE_SPAPR_DRC_PHYSICAL)
|
|
|
|
#define SPAPR_DRC_PHYSICAL(obj) OBJECT_CHECK(sPAPRDRConnector, (obj), \
|
|
|
|
TYPE_SPAPR_DRC_PHYSICAL)
|
|
|
|
|
|
|
|
#define TYPE_SPAPR_DRC_LOGICAL "spapr-drc-logical"
|
|
|
|
#define SPAPR_DRC_LOGICAL_GET_CLASS(obj) \
|
|
|
|
OBJECT_GET_CLASS(sPAPRDRConnectorClass, obj, TYPE_SPAPR_DRC_LOGICAL)
|
|
|
|
#define SPAPR_DRC_LOGICAL_CLASS(klass) \
|
|
|
|
OBJECT_CLASS_CHECK(sPAPRDRConnectorClass, klass, \
|
|
|
|
TYPE_SPAPR_DRC_LOGICAL)
|
|
|
|
#define SPAPR_DRC_LOGICAL(obj) OBJECT_CHECK(sPAPRDRConnector, (obj), \
|
|
|
|
TYPE_SPAPR_DRC_LOGICAL)
|
|
|
|
|
|
|
|
#define TYPE_SPAPR_DRC_CPU "spapr-drc-cpu"
|
|
|
|
#define SPAPR_DRC_CPU_GET_CLASS(obj) \
|
|
|
|
OBJECT_GET_CLASS(sPAPRDRConnectorClass, obj, TYPE_SPAPR_DRC_CPU)
|
|
|
|
#define SPAPR_DRC_CPU_CLASS(klass) \
|
|
|
|
OBJECT_CLASS_CHECK(sPAPRDRConnectorClass, klass, TYPE_SPAPR_DRC_CPU)
|
|
|
|
#define SPAPR_DRC_CPU(obj) OBJECT_CHECK(sPAPRDRConnector, (obj), \
|
|
|
|
TYPE_SPAPR_DRC_CPU)
|
|
|
|
|
|
|
|
#define TYPE_SPAPR_DRC_PCI "spapr-drc-pci"
|
|
|
|
#define SPAPR_DRC_PCI_GET_CLASS(obj) \
|
|
|
|
OBJECT_GET_CLASS(sPAPRDRConnectorClass, obj, TYPE_SPAPR_DRC_PCI)
|
|
|
|
#define SPAPR_DRC_PCI_CLASS(klass) \
|
|
|
|
OBJECT_CLASS_CHECK(sPAPRDRConnectorClass, klass, TYPE_SPAPR_DRC_PCI)
|
|
|
|
#define SPAPR_DRC_PCI(obj) OBJECT_CHECK(sPAPRDRConnector, (obj), \
|
|
|
|
TYPE_SPAPR_DRC_PCI)
|
|
|
|
|
|
|
|
#define TYPE_SPAPR_DRC_LMB "spapr-drc-lmb"
|
|
|
|
#define SPAPR_DRC_LMB_GET_CLASS(obj) \
|
|
|
|
OBJECT_GET_CLASS(sPAPRDRConnectorClass, obj, TYPE_SPAPR_DRC_LMB)
|
|
|
|
#define SPAPR_DRC_LMB_CLASS(klass) \
|
|
|
|
OBJECT_CLASS_CHECK(sPAPRDRConnectorClass, klass, TYPE_SPAPR_DRC_LMB)
|
|
|
|
#define SPAPR_DRC_LMB(obj) OBJECT_CHECK(sPAPRDRConnector, (obj), \
|
|
|
|
TYPE_SPAPR_DRC_LMB)
|
|
|
|
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
/*
|
|
|
|
* Various hotplug types managed by sPAPRDRConnector
|
|
|
|
*
|
|
|
|
* these are somewhat arbitrary, but to make things easier
|
|
|
|
* when generating DRC indexes later we've aligned the bit
|
|
|
|
* positions with the values used to assign DRC indexes on
|
|
|
|
* pSeries. we use those values as bit shifts to allow for
|
|
|
|
* the OR'ing of these values in various QEMU routines, but
|
|
|
|
* for values exposed to the guest (via DRC indexes for
|
|
|
|
* instance) we will use the shift amounts.
|
|
|
|
*/
|
|
|
|
typedef enum {
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_SHIFT_CPU = 1,
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_SHIFT_PHB = 2,
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_SHIFT_VIO = 3,
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_SHIFT_PCI = 4,
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_SHIFT_LMB = 8,
|
|
|
|
} sPAPRDRConnectorTypeShift;
|
|
|
|
|
|
|
|
typedef enum {
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_ANY = ~0,
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_CPU = 1 << SPAPR_DR_CONNECTOR_TYPE_SHIFT_CPU,
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_PHB = 1 << SPAPR_DR_CONNECTOR_TYPE_SHIFT_PHB,
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_VIO = 1 << SPAPR_DR_CONNECTOR_TYPE_SHIFT_VIO,
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_PCI = 1 << SPAPR_DR_CONNECTOR_TYPE_SHIFT_PCI,
|
|
|
|
SPAPR_DR_CONNECTOR_TYPE_LMB = 1 << SPAPR_DR_CONNECTOR_TYPE_SHIFT_LMB,
|
|
|
|
} sPAPRDRConnectorType;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* set via set-indicator RTAS calls
|
|
|
|
* as documented by PAPR+ 2.7 13.5.3.4, Table 177
|
|
|
|
*
|
|
|
|
* isolated: put device under firmware control
|
|
|
|
* unisolated: claim OS control of device (may or may not be in use)
|
|
|
|
*/
|
|
|
|
typedef enum {
|
|
|
|
SPAPR_DR_ISOLATION_STATE_ISOLATED = 0,
|
|
|
|
SPAPR_DR_ISOLATION_STATE_UNISOLATED = 1
|
|
|
|
} sPAPRDRIsolationState;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* set via set-indicator RTAS calls
|
|
|
|
* as documented by PAPR+ 2.7 13.5.3.4, Table 177
|
|
|
|
*
|
|
|
|
* unusable: mark device as unavailable to OS
|
|
|
|
* usable: mark device as available to OS
|
|
|
|
* exchange: (currently unused)
|
|
|
|
* recover: (currently unused)
|
|
|
|
*/
|
|
|
|
typedef enum {
|
|
|
|
SPAPR_DR_ALLOCATION_STATE_UNUSABLE = 0,
|
|
|
|
SPAPR_DR_ALLOCATION_STATE_USABLE = 1,
|
|
|
|
SPAPR_DR_ALLOCATION_STATE_EXCHANGE = 2,
|
|
|
|
SPAPR_DR_ALLOCATION_STATE_RECOVER = 3
|
|
|
|
} sPAPRDRAllocationState;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* LED/visual indicator state
|
|
|
|
*
|
|
|
|
* set via set-indicator RTAS calls
|
|
|
|
* as documented by PAPR+ 2.7 13.5.3.4, Table 177,
|
|
|
|
* and PAPR+ 2.7 13.5.4.1, Table 180
|
|
|
|
*
|
|
|
|
* inactive: hotpluggable entity inactive and safely removable
|
|
|
|
* active: hotpluggable entity in use and not safely removable
|
|
|
|
* identify: (currently unused)
|
|
|
|
* action: (currently unused)
|
|
|
|
*/
|
|
|
|
typedef enum {
|
|
|
|
SPAPR_DR_INDICATOR_STATE_INACTIVE = 0,
|
|
|
|
SPAPR_DR_INDICATOR_STATE_ACTIVE = 1,
|
|
|
|
SPAPR_DR_INDICATOR_STATE_IDENTIFY = 2,
|
|
|
|
SPAPR_DR_INDICATOR_STATE_ACTION = 3,
|
|
|
|
} sPAPRDRIndicatorState;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* returned via get-sensor-state RTAS calls
|
|
|
|
* as documented by PAPR+ 2.7 13.5.3.3, Table 175:
|
|
|
|
*
|
|
|
|
* empty: connector slot empty (e.g. empty hotpluggable PCI slot)
|
|
|
|
* present: connector slot populated and device available to OS
|
|
|
|
* unusable: device not currently available to OS
|
|
|
|
* exchange: (currently unused)
|
|
|
|
* recover: (currently unused)
|
|
|
|
*/
|
|
|
|
typedef enum {
|
|
|
|
SPAPR_DR_ENTITY_SENSE_EMPTY = 0,
|
|
|
|
SPAPR_DR_ENTITY_SENSE_PRESENT = 1,
|
|
|
|
SPAPR_DR_ENTITY_SENSE_UNUSABLE = 2,
|
|
|
|
SPAPR_DR_ENTITY_SENSE_EXCHANGE = 3,
|
|
|
|
SPAPR_DR_ENTITY_SENSE_RECOVER = 4,
|
|
|
|
} sPAPRDREntitySense;
|
|
|
|
|
|
|
|
typedef enum {
|
2015-09-01 02:53:52 +03:00
|
|
|
SPAPR_DR_CC_RESPONSE_NEXT_SIB = 1, /* currently unused */
|
|
|
|
SPAPR_DR_CC_RESPONSE_NEXT_CHILD = 2,
|
|
|
|
SPAPR_DR_CC_RESPONSE_NEXT_PROPERTY = 3,
|
|
|
|
SPAPR_DR_CC_RESPONSE_PREV_PARENT = 4,
|
|
|
|
SPAPR_DR_CC_RESPONSE_SUCCESS = 0,
|
|
|
|
SPAPR_DR_CC_RESPONSE_ERROR = -1,
|
|
|
|
SPAPR_DR_CC_RESPONSE_CONTINUE = -2,
|
|
|
|
SPAPR_DR_CC_RESPONSE_NOT_CONFIGURABLE = -9003,
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
} sPAPRDRCCResponse;
|
|
|
|
|
2017-06-04 13:26:25 +03:00
|
|
|
/* rtas-configure-connector state */
|
|
|
|
typedef struct sPAPRConfigureConnectorState {
|
|
|
|
int fdt_offset;
|
|
|
|
int fdt_depth;
|
|
|
|
} sPAPRConfigureConnectorState;
|
|
|
|
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
typedef struct sPAPRDRConnector {
|
|
|
|
/*< private >*/
|
|
|
|
DeviceState parent;
|
|
|
|
|
|
|
|
uint32_t id;
|
|
|
|
Object *owner;
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
/* sensor/indicator states */
|
|
|
|
uint32_t isolation_state;
|
|
|
|
uint32_t allocation_state;
|
|
|
|
uint32_t indicator_state;
|
|
|
|
|
|
|
|
/* configure-connector state */
|
|
|
|
void *fdt;
|
|
|
|
int fdt_start_offset;
|
|
|
|
bool configured;
|
2017-06-04 13:26:25 +03:00
|
|
|
sPAPRConfigureConnectorState *ccs;
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
|
|
|
|
bool awaiting_release;
|
2016-04-01 01:27:37 +03:00
|
|
|
bool signalled;
|
2016-05-12 06:48:21 +03:00
|
|
|
bool awaiting_allocation;
|
spapr: fix memory hot-unplugging
If, once the kernel has booted, we try to remove a memory
hotplugged while the kernel was not started, QEMU crashes on
an assert:
qemu-system-ppc64: hw/virtio/vhost.c:651:
vhost_commit: Assertion `r >= 0' failed.
...
#4 in vhost_commit
#5 in memory_region_transaction_commit
#6 in pc_dimm_memory_unplug
#7 in spapr_memory_unplug
#8 spapr_machine_device_unplug
#9 in hotplug_handler_unplug
#10 in spapr_lmb_release
#11 in detach
#12 in set_allocation_state
#13 in rtas_set_indicator
...
If we take a closer look to the guest kernel log, we can see when
we try to unplug the memory:
pseries-hotplug-mem: Attempting to hot-add 4 LMB(s)
What happens:
1- The kernel has ignored the memory hotplug event because
it was not started when it was generated.
2- When we hot-unplug the memory,
QEMU starts to remove the memory,
generates an hot-unplug event,
and signals the kernel of the incoming new event
3- as the kernel is started, on the QEMU signal, it reads
the event list, decodes the hotplug event and tries to
finish the hotplugging.
4- QEMU receive the the hotplug notification while it
is trying to hot-unplug the memory. This moves the memory
DRC to an invalid state
This patch prevents this by not allowing to set the allocation
state to USABLE while the DRC is awaiting release.
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1432382
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-03-28 15:09:34 +03:00
|
|
|
bool awaiting_allocation_skippable;
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
|
|
|
|
/* device pointer, via link property */
|
|
|
|
DeviceState *dev;
|
|
|
|
} sPAPRDRConnector;
|
|
|
|
|
|
|
|
typedef struct sPAPRDRConnectorClass {
|
|
|
|
/*< private >*/
|
|
|
|
DeviceClass parent;
|
|
|
|
|
|
|
|
/*< public >*/
|
2017-06-04 13:25:17 +03:00
|
|
|
sPAPRDRConnectorTypeShift typeshift;
|
2017-06-04 13:26:54 +03:00
|
|
|
const char *typename; /* used in device tree, PAPR 13.5.2.6 & C.6.1 */
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
|
2017-06-07 04:26:52 +03:00
|
|
|
sPAPRDREntitySense (*dr_entity_sense)(sPAPRDRConnector *drc);
|
|
|
|
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
/* accessors for guest-visible (generally via RTAS) DR state */
|
2015-09-11 00:11:02 +03:00
|
|
|
uint32_t (*set_isolation_state)(sPAPRDRConnector *drc,
|
|
|
|
sPAPRDRIsolationState state);
|
|
|
|
uint32_t (*set_indicator_state)(sPAPRDRConnector *drc,
|
|
|
|
sPAPRDRIndicatorState state);
|
|
|
|
uint32_t (*set_allocation_state)(sPAPRDRConnector *drc,
|
|
|
|
sPAPRDRAllocationState state);
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
const char *(*get_name)(sPAPRDRConnector *drc);
|
|
|
|
|
|
|
|
/* QEMU interfaces for managing hotplug operations */
|
|
|
|
void (*attach)(sPAPRDRConnector *drc, DeviceState *d, void *fdt,
|
|
|
|
int fdt_start_offset, bool coldplug, Error **errp);
|
2017-05-22 22:35:48 +03:00
|
|
|
void (*detach)(sPAPRDRConnector *drc, DeviceState *d, Error **errp);
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
bool (*release_pending)(sPAPRDRConnector *drc);
|
2016-04-01 01:27:37 +03:00
|
|
|
void (*set_signalled)(sPAPRDRConnector *drc);
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
} sPAPRDRConnectorClass;
|
|
|
|
|
2017-06-02 06:49:20 +03:00
|
|
|
uint32_t spapr_drc_index(sPAPRDRConnector *drc);
|
|
|
|
sPAPRDRConnectorType spapr_drc_type(sPAPRDRConnector *drc);
|
|
|
|
|
2017-06-04 13:25:17 +03:00
|
|
|
sPAPRDRConnector *spapr_dr_connector_new(Object *owner, const char *type,
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
uint32_t id);
|
2017-06-04 13:26:03 +03:00
|
|
|
sPAPRDRConnector *spapr_drc_by_index(uint32_t index);
|
|
|
|
sPAPRDRConnector *spapr_drc_by_id(const char *type, uint32_t id);
|
2015-05-07 08:33:51 +03:00
|
|
|
int spapr_drc_populate_dt(void *fdt, int fdt_offset, Object *owner,
|
|
|
|
uint32_t drc_type_mask);
|
spapr_drc: initial implementation of sPAPRDRConnector device
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>
2015-05-07 08:33:43 +03:00
|
|
|
|
2016-06-29 14:47:03 +03:00
|
|
|
#endif /* HW_SPAPR_DRC_H */
|