Re: [libvirt] virNodeDevice APIs and VFIO
On Tue, Apr 23, 2013 at 10:52:09AM -0400, Laine Stump wrote:
Yesterday for the first time I consciously noticed the
virNodeDeviceDettach and virNodeDeviceReAttach APIs, and found that they
are hardcoded to bind to/unbind from the pci-stub driver for qemu, and
the "pciback" driver for Xen. If we want these APIs to be useful for
VFIO, they will need to bind to the vfio driver instead, but there is
currently no method in those APIs to specify which driver to bind to.
I guess we could do this with new virNodeDeviceDetachFlags() and
virNodeDeviceReAttachFlags() APIs which have a flag to indicate vfio,
but before going to that trouble I'd like to know if these APIs are
actually used or if they are deprecated (they don't seem to be of any
use if the hostdev devices you're assigning have "managed='yes'" -
as
far as I can see, setting managed='yes' just makes the bind/unbind from
the stub driver an automatic part of assigning/un-assigning the device
to a guest).
The rationale for managed="no", is that in more security paranoid/locked
down environments, admins will not want libvirtd screwing around with
kernel module drivers. The admin would manually setup "pciback" binding
ahead of time when configuring the host. I think we need to continue to
support this scenario in the VFIO world.
If we go down the route of extending <hostdev> to have support for
<driver name="vfio|qemu"/>
Then, this says that the virNodeDevice{Detach,ReAttach} methods need
to have new variants which take a 'const char *drivername' parameter.
NB, the values of 'drivername' would match those used in the domain
XML <driver> element - they would *not* be kernel module names.
So we'd call
virNodeDeviceDetachDriver(dev, "qemu");
virNodeDeviceDetachDriver(dev, "vfio");
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|