On Wed, 2009-02-25 at 17:51 +0000, Daniel P. Berrange wrote: > On Tue, Feb 24, 2009 at 10:21:48PM +0000, Mark McLoughlin wrote: > > Before starting a guest virNodeDeviceAttach() is intended > > to be called on all node devices to be assigned to a guest, > > followed by virNodeDeviceReset() on those devices. > > > > Once the guest has been shutdown, virNodeDeviceReset() > > followed by virNodeDeviceReAttach() should be called in > > order to make the device available to the host again. > > > > This patch merely adds the APIs and stubs out the driver > > implementations. > > 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. It needs to be a separate API from dettach() because reset() may succeed (in future) if e.g. you dettach() all the functions on a multi-function device before calling reset() on one of those functions. > I think the attach/detach functions should be in the nodedev > driver too, because they're not really part of the HV functionality. > On modern Linux kernels, both Xen & KVM (and any other users) have > the same pci-stub.ko code for managed driver binding. On older Xen > kernels, there is the functionally equivalent pci-back.ko. Sure, but the logic to choose between pci-stub vs. pci-back is HV specific, right? I'm sure more of this could be re-factored to be in common for the Xen implementation, but it makes sense to me to do that when we actually do the Xen implementation. The code should be very easy to re-factor. > A similar capability is really needed for USB devices, to disconnect > them from any host USB driver, and that's not HV specific either. Yep, I haven't investigated the USB side of things - looks like we need remove_id support in USB sysfs too. Cheers, Mark. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list