+++ This bug was initially created as a clone of Bug #807023 +++

Description of problem:
libvirt appears to always assume a device_del is successful.  This is not always the case.  Issuing a device_del simply registers a request to eject the device with the guest, it doesn't guarantee removal.  There are numerous reasons a guest may fail to release the device, however, when this happens libvirt does not report error and continues as if the removal was successful.

In my case I see this with a tg3 devices assigned to the guest.  The guest driver attempts to do a power state transition on the device, which doesn't work, and gets stuck.  The guest never calls the eject method for the device, but libvirt continues to unbind the device from pci-stub and pretend the removal was successful.

We need a QMP event to be reported when a device is released by a guest so that libvirt can detect successful device_del.

Version-Release number of selected component (if applicable):
libvirt-0.9.10-5.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Assign a tg3 device to a guest
2. Bring up the interface in the guest
3. Try to remove the device
  
Actual results:
libvirt reports success and unbinds the device from pci-stub, meanwhile the guest still owns the device (/proc/pid/fd still reports all the device file descriptors open).

Expected results:
libvirt checks for device removal and reports error after some timeout and doesn't unbind device from pci-stub.

Additional info:

--- Additional comment from dallan on 2012-03-28 15:23:45 UTC ---

This seems like a situation that's going to be difficult for libvirt to resolve without additional information from qemu.  Jiri, what do you think?

--- Additional comment from jdenemar on 2012-03-29 15:00:19 UTC ---

It won't be easy even with additional information from qemu. We would need to change detach API to be just a request for detaching and generate an event (emitted by qemu) when the device gets detached. However, this would mean the semantics of the api changed so it might be difficult to deal with, although one can argue that it didn't work with current semantics anyway.