Re: [libvirt] [Qemu-devel] qapi DEVICE_DELETED event issued *before* instance_finalize?!
On 06/09/2016 04:18, Alex Williamson wrote:
On Mon, 5 Sep 2016 11:36:55 +0200
Paolo Bonzini <pbonzini(a)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