On 06/09/2016 04:18, Alex Williamson wrote:
On Mon, 5 Sep 2016 11:36:55 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote:
DEVICE_DELETED does have a meaning: management cannot talk to the device anymore in QMP once it is raised.
It seems like this is just pointing out another flaw in the semantics of DEVICE_DELETED, a device can linger without a device id, so there's no way to reference it via QMP. QEMU can't signal anything more about the device, nor can the VM admin perform any further operations on it. It's like detecting planets around distant stars, libvirt can't actually see the device, it can only monitor the affects the device has on the VM. This is broken and it seems like the fix is to push both the release of the device id and the DEVICE_DELETED notification until after the instance_finalize callback.
You can't do that. Think of it as DEVICE_DELETED being "removal" and instance_finalize being "reference count has gone to 0". You cannot make the reference count go to 0 unless you have disconnected the device from the parent, and the parent is the one that remembers the device id.
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?
This immediately sounds like the wrong path. A) Why is this vfio specific?
Because VFIO doesn't have a separate backend object. instance_finalize is already where the backends are released. You cannot for example reuse a character device until instance_finalize (no event is generated, but we could certainly add one to qemu-char.c if deemed useful). VFIO_DELETED is just another example of the same thing. It just happens that the host device is not a separate "-object vfio-backend-pci,sysfs=..." but it's embedded in "-device vfio-pci" so the code for the new event must go in hw/vfio rather than a hypothetical backends/vfio. I'm not saying that VFIO should have a separate backend object, that would probably be overengineering. But in some cases you get saner semantics if you think of VFIO as a composition of two things.
B) Without a device id, how are we going to signal an event?
For example by sysfs path or host device path---it makes sense to use properties of the backend since this signals that the backend is now free. Paolo