[libvirt] virNodeDevice APIs and VFIO

Daniel P. Berrange berrange at redhat.com
Tue Apr 23 15:46:27 UTC 2013


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 :|




More information about the libvir-list mailing list