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?
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.