On Wed, 2009-02-25 at 19:58 +0000, Daniel P. Berrange wrote:
While I can see a point in providing public APIs to attach/detach drivers to devices - because we need this for Xen driver PCI passthrough, I'm not sure theres a compelling need for exposing a reset function, because both Xen & your KVM impl are quite happy doing the resets themselves.
The idea with the reset function is that calling reset is a way for the app to query whether this is an assignable device - e.g. if the user chooses a given NIC to pass through in one of the early screens in virt-manager, we can give a "you can't assign that device" error at that point rather than just having the guest fail to start up much later on.
I wonder if we should generalize that beyond just host device, to cover VM device hotplug in general, passing in the same XML doc you'd use for the subsequent virDomainAttachDevice() call.
virDomainCanAttachDevice(virDomainPtr dom, const char *xml);
Though, obviously that won't help for scenarios before a virDomainPtr exists. So might also want a way to ask whether a device is likely to be supported before creating a VM
virConnectSupportsDevice(virConnectPtr conn, const char *xml)
But then maybe this is getting into overkill, and just rename the reset function to
int virNodeDeviceAssignable(virNodeDevicePtr dev);
so we're not explicitly saying 'reset' is the test we're doing, even though that may be the internal impl
I see what you're getting at - we may in future want have an "is assignable" API that goes beyond just "does reset" work and it would be a pity to have to add yet another API. However, "is assignable" in the context of a hotplugging into a running guest is an operation on a given domain - e.g. if you're hotplugging a device on the same bus as a device previously assigned to the same guest, then that's allowed. "reset" seems to me to be a pretty sane operation to expose - especially for what we're now calling "non-managed" assigned devices. It doesn't cover all cases, but it's an step in the right direction. Cheers, Mark.