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. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list