On 05/09/2016 11:23, Markus Armbruster wrote:
On the other hand, it is clearly documented that the DEVICE_DELETED event is sent as soon as guest acknowledges completion of device removal. So libvirt's buggy if we'd follow documentation strictly. But then again, I don't see much information value in "guest has detached device but qemu hasn't yet" event. Libvirt would ignore such event.
Unless I'm missing something, libvirt needs an event that signals "Guest and QEMU are done with this device". Current DEVICE_DELETED isn't.
Can we imagine a use for current DEVICE_DELETED, i.e. "Guest is done, but QEMU isn't"?
Would anything break if we changed semantics of DEVICE_DELETED to what libvirt actually needs?
If the answers are "no" and "no", let's do it.
There is a subtle aspect of this. After the current DEVICE_DELETED, the device id is not used any more. So technically you could have device_add bar,id=foo device_del foo // something in QEMU prevents the device from going away? // for example there is a storage issue that blocks completion // of a read(), and bar is a storage device device_add bar,id=foo device_del foo // which foo is being deleted? The old one or the new one? event DEVICE_DELETED DEVICE_DELETED does have a meaning: management cannot talk to the device anymore in QMP once it is raised. Technically what libvirt wants to know for VFIO is not whether the device is gone; it's whether the device's _backend_ (the VFIO file descriptor) is gone. The device backend could have been a separate QOM object, but it isn't. So perhaps we need a new event that is specific to VFIO? Thanks, Paolo