[lkml]   [2020]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/7] vfio/pci: SR-IOV support
On Tue, 4 Feb 2020 23:01:09 -0800
Christoph Hellwig <> 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.


 \ /
  Last update: 2020-02-05 14:59    [W:0.157 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site