On 06/09/2016 04:18, Alex Williamson wrote: > On Mon, 5 Sep 2016 11:36:55 +0200 > Paolo Bonzini <pbonzini@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list