[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event |
Date: |
Fri, 08 Mar 2013 12:58:13 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) |
Osier Yang <address@hidden> writes:
> On 2013年03月08日 16:50, Markus Armbruster wrote:
>> Osier Yang<address@hidden> writes:
>>
>>> I'm wondering if it could be long time to wait for the device_del
>>> completes (AFAIK from previous bugs, it can be, though it should be
>>> fine for most of the cases). If it's too long, it will be a problem
>>> for management, because it looks like hanging. We can have a timeout
>>> for the device_del in libvirt, but the problem is the device_del
>>> can be still in progress by qemu, which could cause the inconsistency.
>>> Unless qemu has some command to cancel the device_del.
>>
>> I'm afraid cancelling isn't possible, at least not for PCI.
>>
>> Here's how device_del works for PCI when it works, roughly:
>>
>> 1. device_del asks the device model to unplug itself.
>>
>> 2. PCI device models delegate the job to the device model providing
>> their PCI bus. Let's assume it's our PIIX3/PIIX4 mongrel. That one
>> puts an unplug request into PIIX4 function 3 where guest ACPI can see
>> it, and triggers its interrupt. Then it immediately sends the QMP
>> success reply.
>>
>> 3. Guest ACPI (SeaBIOS) services the interrupt. It finds the unplug
>> request, and asks the guest OS nicely to give up the device.
>>
>> 4. If the guest OS has a working ACPI driver, and it feels like giving
>> up the device, it does so, and tells ACPI when it's done.
>>
>> 5. Guest ACPI cleans up whatever it needs cleaned up, and signals
>> successful unplug by writing the slog number to a PIIX4 function 3
>> register.
>>
>> 6. The PIIX device destroys the device in that slot.
>>
>> I call this the ACPI unplug dance.
>>
>> We don't control steps 3..5.
>>
>> There's no way for the guest to tell us "I got your unplug request, but
>> I'm not going to honor it". Even if their was, a guest without a
>> working ACPI driver wouldn't use it, so we couldn't rely on it anyway.
>>
>> There's no way for us to tell the guest "I changed my mind on this
>> unplug". All we can do is wait and see. Either the device goes away,
>> or it stays.
>
> Hum, as I replied to Jirka in later mail, IMHO it needs to change
> libvirt detaching APIs to either wait for the event or find the
> device is really removed by polling before returning success. But
> it sounds to me that how long it takes to wait or polling is really
> depended?
Time between device_del and event DEVICE_DELETED event is *unbounded*.
Could be instantaneous, could be never, could be anything in between.
I'd expect it to be either fairly short or never most of the time in
practice.
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, (continued)
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Michael S. Tsirkin, 2013/03/07
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Markus Armbruster, 2013/03/07
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Michael S. Tsirkin, 2013/03/07
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Andreas Färber, 2013/03/07
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Michael S. Tsirkin, 2013/03/07
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Osier Yang, 2013/03/08
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Markus Armbruster, 2013/03/08
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Jiri Denemark, 2013/03/08
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Osier Yang, 2013/03/08
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Osier Yang, 2013/03/08
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event,
Markus Armbruster <=
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Markus Armbruster, 2013/03/07
- Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Michael S. Tsirkin, 2013/03/07
Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event, Eric Blake, 2013/03/06