[libvirt] RFC: Check if the host device is assignable earlier
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
On 09/23/2012 10:29 PM, Osier Yang wrote:
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?
Yes, failing earlier if it can be proven that the passthrough will not ever succeed seems worthwhile.
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
Why would we need a new API? We can already get at each virNodeDevicePtr (see 'virsh nodedev-list') and learn about each device (see 'virsh nodedev-dumpxml'); this seems like something that you would just add an addditional XML element to that existing API instead of needing a new API. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 2012年09月25日 00:32, Eric Blake wrote:
On 09/23/2012 10:29 PM, Osier Yang wrote:
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?
Yes, failing earlier if it can be proven that the passthrough will not ever succeed seems worthwhile.
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
Why would we need a new API? We can already get at each virNodeDevicePtr (see 'virsh nodedev-list')
(see 'virsh nodedev-dumpxml');
New filtering flags for virNodeListAllDevices makes sense, but it need to find a way to associate nodedev driver and the HV driver together (it should be the time to do this now, there as similiar request before as far as I could recall), to check whether the device is being used by some guest. and learn about each device this seems like something that you would
just add an addditional XML element
Yeah, we should have an new XML tag to expose the info anyway, but for an upper layer app, it might be better to known if the device is assignable directly, instead of parsing the device XML? (assuming virsh attach-device will be one of the caller). Regards, Osier
participants (2)
-
Eric Blake -
Osier Yang