Re: [libvirt] [PATCH 2/5] Add virNodeDeviceAttach()/ReAttach()/Reset() APIs

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?