qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 12/12] spapr_pci: emit hotplug add/remove events


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 12/12] spapr_pci: emit hotplug add/remove events during hotplug
Date: Tue, 26 Aug 2014 14:36:12 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0


On 19.08.14 02:21, Michael Roth wrote:
> From: Tyrel Datwyler <address@hidden>
> 
> 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 <address@hidden>
> Signed-off-by: Michael Roth <address@hidden>
> ---
>  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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]