Re: [PATCH] Enable SR-IOV instantiation through /sys file

[Alexander Duyck]

On Sat, Oct 28, 2017 at 11:16 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> On Fri, Oct 27, 2017 at 11:20:41PM +0000, Duyck, Alexander H wrote:
>> I don't see this so much as a security problem per-se. It all depends
>> on the hardware setup. If I recall correctly, there are devices where
>> the PF function doesn't really do much other than act as a bit more
>> heavy-weight VF, and the actual logic is handled by a firmware engine
>> on the device.
>
> Can you cite an example?  While those surely could exist in theory,
> I can't think of a practical example.

If I recall the neterion vxge driver fell into that category if I
recall correctly. Basically the hardware is preconfigured for some
number of VFs and their driver just calls pci_enable_sriov and enables
them.

One other thing I forgot about is the fact that we already have
drivers such as igb, ixgbe, and vxge floating around that will leave
SR-IOV enabled if the driver is loaded while VFs are direct assigned
to guests. As a side effect we can sort of already support assigning
vfio-pci to a driver that has SR-IOV enabled.

> Maybe we can start with the practical use case for this patch.  That
> is what device is this intended for?

If I am not mistaken the typical use case for a patch like this is to
support loading something like DPDK on a networking device PF, whlie
the VFs are assigned to virtualized guests and/or containers. It would
move the control of the PF/VFs into use space, but in the grand scheme
of things it isn't much different then when a virtualized guest has a
VF and has no direct control over the configuration of it since the
host is managing that.

So if the root user is enabling SR-IOV and allocating VFs on a device
that is running the vfio-pci driver the assumption is that the root
user must be trusting the application that is running on top of the
vfio-pci driver to behave correctly.