On Wed, 5 Feb 2020 07:57:21 +0000 "Liu, Yi L" <yi.l.liu@xxxxxxxxx> wrote: > Hi Alex, > > Silly questions on the background: > > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > Sent: Wednesday, February 5, 2020 7:06 AM > > Subject: [RFC PATCH 0/7] vfio/pci: SR-IOV support > > > > There seems to be an ongoing desire to use userspace, vfio-based > > drivers for both SR-IOV PF and VF devices. > > Is this series to make PF be bound-able to vfio-pci even SR-IOV is > enabled on such PFs? If yes, is it allowed to assign PF to a VM? or > it can only be used by userspace applications like DPDK? No, this series does not change the behavior of vfio-pci with respect to probing a PF where VFs are already enabled. This is still disallowed. I haven't seen a use case that requires this and allowing it tends to subvert the restrictions here. For instance, if an existing VF is already in use by a vfio-pci driver, the PF can transition from a trusted host driver to an unknown userspace driver. > > The fundamental issue > > with this concept is that the VF is not fully independent of the PF > > driver. Minimally the PF driver might be able to deny service to the > > VF, VF data paths might be dependent on the state of the PF device, > > or the PF my have some degree of ability to inspect or manipulate the > > VF data. It therefore would seem irresponsible to unleash VFs onto > > the system, managed by a user owned PF. > > > > 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. > > > > The next issue we need to address is how we let userspace drivers > > opt-in to this participation with the PF driver. We do not want an > > admin to be able to unwittingly assign one of these VFs to a tenant > > that isn't working in collaboration with the PF driver. We could use > > IOMMU grouping, but this seems to push too far towards tightly coupled > > PF and VF drivers. This series introduces a "VF token", implemented > > as a UUID, as a shared secret between PF and VF drivers. The token > > needs to be set by the PF driver and used as part of the device > > matching by the VF driver. Provisions in the code also account for > > restarting the PF driver with active VF drivers, requiring the PF to > > use the current token to re-gain access to the PF. > > How about the scenario in which PF driver is vfio-based userspace > driver but VF drivers are mixed. This means not all VFs are bound > to vfio-based userspace driver. Is it also supported here? :-) It's allowed. Userspace VF drivers will need to participate in the VF token scheme, host drivers may be bound to VFs normally after removing the default driver_override. Thanks, Alex
