Messages in this thread |  | | Date | Wed, 5 Feb 2020 06:58:36 -0700 | From | Alex Williamson <> | Subject | Re: [RFC PATCH 0/7] vfio/pci: SR-IOV support |
| |
On Tue, 4 Feb 2020 23:01:09 -0800 Christoph Hellwig <hch@infradead.org> 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
|  |