[libvirt] [RFC PATCH] hostdev: add support for "managed='detach'"

[Daniel P. Berrange]

On Thu, Mar 17, 2016 at 12:18:49PM -0600, Alex Williamson wrote:
> On Thu, 17 Mar 2016 17:59:53 +0000
> "Daniel P. Berrange" <berrange at redhat.com> wrote:
> 
> > 
> > I don't think it is a significant burden really. Apps which want this
> > blacklisted forever likely want to setup the modprobe blacklist anyway
> > to stop the initial bind at boot up and instead permanently reserve
> > the device. This stops the device being used at startup - eg if we
> > have a bunch of NICs to be given to guests, you don't want the host
> > OS to automatically configure them and give them IP addresses on the
> > host before we start guests. So pre-reserving devices at the host OS
> > level is really want you want todo with data center / cloud management
> > apps like oVirt / OpenStack at least. They could easily use the
> > virNodeDeviceDetach API at the time they decide to assign a device
> > to a guest though.
> 
> modprobe blacklist assumes that all devices managed by a given driver
> are reserved for VM use.  That's very often not the case.  Even with
> SR-IOV VFs, several vendors use the same driver for PF and VF, so
> that's just a poor solution.  For GPU assignment we often recommend
> using pci-stub.ids on the kernel commandline to pre-load the pci-stub
> driver with PCI vendor and device IDs to claim to prevent host drivers
> from attaching, but that also assumes that you want to use everything
> matching those IDs for a VM, which users will quickly find fault with.
> Additionally, using either solution assumes that the device will be
> left entirely alone otherwise, which is also not true.  If I blacklist
> i915 or using pci-stub.ids to make pci-stub claim it, then efifb or
> vesafb is more than happy to make use of it, so it's actually cleaner
> to let i915 grab the device and unbind it when ready.  And of course
> the issue of assuming that the device can go without drivers, which may
> make your user run a headless system.  This is really not the
> simplistic issue that it may seem.  Thanks,

The issues you describe point towards the need for a better blacklisting
facility at the OS level IMHO. eg a way to tell the kernel module to
not automatically bind drivers for devices with a particular device ID.
Combined that with the virNodeDeviceDetach() API usage still feels like
a better solution that adding a managed=detach flag to libvirt.

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