On 19.08.14 02:21, Michael Roth wrote:
> From: Tyrel Datwyler <tyr...@linux.vnet.ibm.com>
>
> 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.
Couldn't they use the pull event mechanism you implement in the previous
patch?
>
> Signed-off-by: Tyrel Datwyler <tyr...@linux.vnet.ibm.com>
> Signed-off-by: Michael Roth <mdr...@linux.vnet.ibm.com>
> ---
> hw/ppc/spapr_pci.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> index 23864ab..17d37c0 100644
> --- a/hw/ppc/spapr_pci.c
> +++ b/hw/ppc/spapr_pci.c
> @@ -944,6 +944,18 @@ static int spapr_device_hotplug_add(DeviceState *qdev,
> PCIDevice *dev)
> drc_entry_slot->state &= ~(uint32_t)INDICATOR_ENTITY_SENSE_MASK;
> drc_entry_slot->state |= encoded; /* and the slot */
>
> + /* reliable unplug requires we wait for a transition from
> + * UNISOLATED->ISOLATED prior to device removal/deletion.
> + * However, slots populated by devices at boot-time will not
> + * have ever been set by guest tools to an UNISOLATED/populated
> + * state, so set this manually in the case of coldplug devices
> + */
> + if (!DEVICE(dev)->hotplugged) {
> + drc_entry_slot->state |= ENCODE_DRC_STATE(1,
> + INDICATOR_ISOLATION_MASK,
> + INDICATOR_ISOLATION_SHIFT);
I think as a general scheme we would like to have the PHB call DRC
(which it knows from a qom link) which raises a qemu_irq to notify the
EPOW device that an event happened. If the EPOW interface is too
complex, I guess we can live with a link and function call too.
Alex
