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

Re: [libvirt] [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event



Osier Yang <jyang redhat com> writes:

> On 2013年03月08日 16:50, Markus Armbruster wrote:
>> Osier Yang<jyang redhat com>  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.


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