Osier Yang <jyang@xxxxxxxxxx> writes: > On 2013年03月08日 16:50, Markus Armbruster wrote: >> Osier Yang<jyang@xxxxxxxxxx> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list