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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list