> -----Original Message----- > From: dev <dev-bounces@xxxxxxxx> On Behalf Of Alex Williamson > Sent: Thursday, February 20, 2020 12:24 AM > To: kvm@xxxxxxxxxxxxxxx > Cc: linux-pci@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; dev@xxxxxxxx; > mtosatti@xxxxxxxxxx; thomas@xxxxxxxxxxxx; bluca@xxxxxxxxxx; > jerinjacobk@xxxxxxxxx; bruce.richardson@xxxxxxxxx; cohuck@xxxxxxxxxx > Subject: [dpdk-dev] [PATCH v2 0/7] vfio/pci: SR-IOV support > > Changes since v1 are primarily to patch 3/7 where the commit log is > rewritten, along with option parsing and failure logging based on upstream > discussions. The primary user visible difference is that option parsing is now > much more strict. If a vf_token option is provided that cannot be used, we > generate an error. As a result of this, opening a PF with a vf_token option > will serve as a mechanism of setting the vf_token. This seems like a more > user friendly API than the alternative of sometimes requiring the option (VFs > in use) and sometimes rejecting it, and upholds our desire that the option is > always either used or rejected. > > This also means that the VFIO_DEVICE_FEATURE ioctl is not the only means > of setting the VF token, which might call into question whether we absolutely > need this new ioctl. Currently I'm keeping it because I can imagine use cases, > for example if a hypervisor were to support SR-IOV, the PF device might be > opened without consideration for a VF token and we'd require the > hypservisor to close and re-open the PF in order to set a known VF token, > which is impractical. > > Series overview (same as provided with v1): > > The synopsis of this series is that we have an ongoing desire to drive PCIe SR- > IOV PFs from userspace with VFIO. There's an immediate need for this with > DPDK drivers and potentially interesting future use cases in virtualization. > We've been reluctant to add this support previously due to the dependency > and trust relationship between the VF device and PF driver. Minimally the PF > driver can induce a denial of service to the VF, but depending on the specific > implementation, the PF driver might also be responsible for moving data > between VFs or have direct access to the state of the VF, including data or > state otherwise private to the VF or VF driver. > > To help resolve these concerns, we introduce a VF token into the VFIO PCI > ABI, which acts as a shared secret key between drivers. The userspace PF > driver is required to set the VF token to a known value and userspace VF > drivers are required to provide the token to access the VF device. If a PF > driver is restarted with VF drivers in use, it must also provide the current > token in order to prevent a rogue untrusted PF driver from replacing a known > driver. The degree to which this new token is considered secret is left to the > userspace drivers, the kernel intentionally provides no means to retrieve the > current token. > > Note that the above token is only required for this new model where both > the PF and VF devices are usable through vfio-pci. Existing models of VFIO > drivers where the PF is used without SR-IOV enabled or the VF is bound to a > userspace driver with an in-kernel, host PF driver are unaffected. > > The latter configuration above also highlights a new inverted scenario that is > now possible, a userspace PF driver with in-kernel VF drivers. > I believe this is a scenario that should be allowed, but should not be enabled > by default. This series includes code to set a default driver_override for VFs > sourced from a vfio-pci user owned PF, such that the VFs are also bound to > vfio-pci. This model is compatible with tools like driverctl and allows the > system administrator to decide if other bindings should be enabled. The VF > token interface above exists only between vfio-pci PF and VF drivers, once a > VF is bound to another driver, the administrator has effectively pronounced > the device as trusted. The vfio-pci driver will note alternate binding in dmesg > for logging and debugging purposes. > > Please review, comment, and test. The example QEMU implementation > provided with the RFC is still current for this version. Thanks, > > Alex Hi Alex, Thanks for enabling this feature support. Tested-by: Vamsi Attunuru <vattunuru@xxxxxxxxxxx> Tested v2 patch set with below DPDK patch. http://patches.dpdk.org/patch/66281/ Regards A Vamsi > > RFC: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__lore.kernel.org_lkml_158085337582.9445.17682266437583505502.stgit- > 40gimli.home_&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=2rpxxNF2qeP0 > 2gVZIWTVrW-6zNZz5-uKt9pRqpR_M3U&m=V-6mKmCTHPZa5jwepXU_- > Ma1_BGF0OWJ_IRCF_p4GVo&s=YnO98PGK9ro7F6_XZTccHdYcZ- > rMMOin0nRFhPD6Uv4&e= > v1: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__lore.kernel.org_lkml_158145472604.16827.15751375540102298130.stgit > - > 40gimli.home_&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=2rpxxNF2qeP0 > 2gVZIWTVrW-6zNZz5-uKt9pRqpR_M3U&m=V-6mKmCTHPZa5jwepXU_- > Ma1_BGF0OWJ_IRCF_p4GVo&s=rvUxLCENwNk0GBYkcsBVVobsLfMb4BV5gtc > 3VqYQTS4&e= > > --- > > Alex Williamson (7): > vfio: Include optional device match in vfio_device_ops callbacks > vfio/pci: Implement match ops > vfio/pci: Introduce VF token > vfio: Introduce VFIO_DEVICE_FEATURE ioctl and first user > vfio/pci: Add sriov_configure support > vfio/pci: Remove dev_fmt definition > vfio/pci: Cleanup .probe() exit paths > > > drivers/vfio/pci/vfio_pci.c | 383 > +++++++++++++++++++++++++++++++++-- > drivers/vfio/pci/vfio_pci_private.h | 10 + > drivers/vfio/vfio.c | 20 +- > include/linux/vfio.h | 4 > include/uapi/linux/vfio.h | 37 +++ > 5 files changed, 426 insertions(+), 28 deletions(-)
