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