Hi,
I think we already got enough bugs which are about "try to assign
a host device, then it fails for not assignable", clearly this
"try and then fails" approach is not nice.
The reason for not assignable can be various. E.g.
* IOMMU or AMD-V is not enabled/supported
* platform doesn't support interrupt remapping
There is no checking for above reasons now, an assignment will
get error till the qemu process started. It's nice if checking
it much earlier, and list whether the host supports device
assignment as a property of capabilities?
* The device can't be unbind/reset
* Is being used by some other guests
* Permission issues
* Other reasons?
It will also be nice if one could known what devices are assignable
(list all assignable devices? this needs to enumerate and try
to unbind/reset/restore the devices, which is not desireable, as
it could breaks work on host, such as NIC). Or whether a device is
assignable (this shouldn't cause any problem when doing checking,
because it's the requested operation, one knowns what he does).
Assuming a new API to determine whether a host device is assignable
for qemu driver, the workflow for the implementation should be:
* If the device is being used (Examine activePciHostdevs,
or activeUsbHostdevs)
* If there is permission issues
* Other possible reasons should be checked before trying to unbind
and reset.
* If the device can be unbind/reset
It's basicly a rough thought, any idea is welcomed.
Regards,
Osier
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list