[libvirt] [Qemu-devel] qapi DEVICE_DELETED event issued *before* instance_finalize?!

[Paolo Bonzini]

On 06/09/2016 04:18, Alex Williamson wrote:
> On Mon, 5 Sep 2016 11:36:55 +0200
> Paolo Bonzini <pbonzini at 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