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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list