Re: [PATCH v2 0/2] VFIO SRIOV support

[Alex Williamson <alex.williamson@redhat.com>]

On Tue, 19 Jul 2016 07:06:34 +0000
"Tian, Kevin" <kevin.tian@intel.com> wrote:

> > From: Alex Williamson
> > Sent: Tuesday, July 19, 2016 5:34 AM
> > 
> > On Sun, 17 Jul 2016 13:05:21 +0300
> > Haggai Eran <haggaie@mellanox.com> wrote:
> >   
> > > On 7/14/2016 8:03 PM, Alex Williamson wrote:  
> > > >> 2. Add an owner_pid to struct vfio_group and make sure in  
> > vfio_group_get_device_fd that  
> > > >> > the PFs  vfio_group is owned by the same process as the one that is trying to get  
> > a fd for a VF.  
> > > > This only solves a very specific use case, it doesn't address any of
> > > > the issues where the VF struct device in the host kernel might get
> > > > bound to another driver.  
> > > The current patch uses driver_override to make the kernel use VFIO for
> > > all the new VFs. It still allows the host kernel to bind them to another
> > > driver, but that would require an explicit action on the part of the
> > > administrator. Don't you think that is enough?  
> > 
> > Binding the VFs to vfio-pci with driver_override just prevents any sort
> > of initial use by native host drivers, it doesn't in any way tie them to
> > the user that created them or prevent any normal operations on the
> > device.  The entire concept of a user-created device is new and
> > entirely separate from a user-owned device as typically used with
> > vfio.  We currently have an assumption with VF assignment that the PF
> > is trusted in the host, that's broken here and I have a hard time
> > blaming it on the admin or management tool for allowing such a thing
> > when it previously hasn't been a possibility.  If nothing else, it
> > seems like we're opening the system for phishing attempts where a user
> > of a PF creates VFs hoping they might be assigned to a victim VM, or
> > worse the host.
> >   
> 
> What about fully virtualizing the SR-IOV capability? The VM is not allowed
> to touch physical SR-IOV capability directly so there would not be a problem
> of user-created devices. Physical SR-IOV is always enabled by admin at
> the host side. Admin can combine any number of VFs (even cross multiple
> compatible devices) in the virtual SR-IOV capability on any passthrough
> device...
> 
> The limitation is that the VM can initially access only PF resource which is 
> usually less than what the entire device provides, so not that efficient
> when the VM doesn't want to enable SR-IOV at all.

Are you suggesting a scenario where we have one PF with SR-IOV disabled
assigned to the user and another PF owned by the host with SR-IOV
enable, we virtualize SR-IOV to the user and use the VFs from the other
PF to act as a "pool" of VFs to be exposed to the user depending on
SR-IOV manipulation?  Something like that could work with existing
vfio, just requiring the QEMU bits to virtualize SR-IOV and mange the
VFs, but I expect it's not a useful model for Mellanox.  I believe it
was Ilya that stated the purpose in exposing SR-IOV was for
development, so I'm assuming they actually want to do development of
the PF SR-IOV enabling in a VM, not just give the illusion of SR-IOV to
the VM.  Thanks,

Alex