On Tue, 4 Feb 2020 23:01:09 -0800 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Tue, Feb 04, 2020 at 04:05:34PM -0700, Alex Williamson wrote: > > We address this in a few ways in this series. First, we can use a bus > > notifier and the driver_override facility to make sure VFs are bound > > to the vfio-pci driver by default. This should eliminate the chance > > that a VF is accidentally bound and used by host drivers. We don't > > however remove the ability for a host admin to change this override. > > That is just such a bad idea. Using VFs in the host is a perfectly > valid use case that you are breaking. vfio-pci currently does not allow binding to a PF with VFs enabled and does not provide an sriov_configure callback, so it's not possible to have VFs on a vfio-pci bound PF. Therefore I'm not breaking any existing use cases. I'm also not preventing VFs from being used in the host, I only set a default driver_override value, which can be replaced if a different driver binding is desired. So I also don't see that I'm breaking a usage model here. I do stand by the idea that VFs sourced from a user owned PF should not by default be used in the host (ie. autoprobed on device add). There's a pci-pf-stub driver that can be used to create VFs on a PF if no userspace access of the PF is required. Thanks, Alex