lkml.org 
[lkml]   [2022]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRE: [PATCH v3] vfio-pci: Provide reviewers and acceptance criteria for vendor drivers
Date
> From: Alex Williamson <alex.williamson@redhat.com>
> Sent: Tuesday, March 15, 2022 4:25 AM
>
> Vendor or device specific extensions for devices exposed to userspace
> through the vfio-pci-core library open both new functionality and new
> risks. Here we attempt to provided formalized requirements and
> expectations to ensure that future drivers both collaborate in their
> interaction with existing host drivers, as well as receive additional
> reviews from community members with experience in this area.
>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Cc: Yishai Hadas <yishaih@nvidia.com>
> Cc: Kevin Tian <kevin.tian@intel.com>
> Acked-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>

Acked-by: Kevin Tian <kevin.tian@intel.com>

> ---
>
> v3:
>
> Relocate to Documentation/driver-api/
> Include index.rst reference
> Cross link from maintainer-entry-profile
> Add Shameer's Ack
>
> v2:
>
> Added Yishai
>
> v1:
>
> Per the proposal here[1], I've collected those that volunteered and
> those that I interpreted as showing interest (alpha by last name). For
> those on the reviewers list below, please R-b/A-b to keep your name as a
> reviewer. More volunteers are still welcome, please let me know
> explicitly; R-b/A-b will not be used to automatically add reviewers but
> are of course welcome. Thanks,
>
> Alex
>
> [1]https://lore.kernel.org/all/20220310134954.0df4bb12.alex.williamson@re
> dhat.com/
>
> Documentation/driver-api/index.rst | 1 +
> .../vfio-pci-vendor-driver-acceptance.rst | 35 ++++++++++++++++++++
> .../maintainer/maintainer-entry-profile.rst | 1 +
> MAINTAINERS | 10 ++++++
> 4 files changed, 47 insertions(+)
> create mode 100644 Documentation/driver-api/vfio-pci-vendor-driver-
> acceptance.rst
>
> diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-
> api/index.rst
> index c57c609ad2eb..da1372c8ec3d 100644
> --- a/Documentation/driver-api/index.rst
> +++ b/Documentation/driver-api/index.rst
> @@ -103,6 +103,7 @@ available subsections can be seen below.
> sync_file
> vfio-mediated-device
> vfio
> + vfio-pci-vendor-driver-acceptance
> xilinx/index
> xillybus
> zorro
> diff --git a/Documentation/driver-api/vfio-pci-vendor-driver-acceptance.rst
> b/Documentation/driver-api/vfio-pci-vendor-driver-acceptance.rst
> new file mode 100644
> index 000000000000..3a108d748681
> --- /dev/null
> +++ b/Documentation/driver-api/vfio-pci-vendor-driver-acceptance.rst
> @@ -0,0 +1,35 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Acceptance criteria for vfio-pci device specific driver variants
> +===============================================================
> =
> +
> +Overview
> +--------
> +The vfio-pci driver exists as a device agnostic driver using the
> +system IOMMU and relying on the robustness of platform fault
> +handling to provide isolated device access to userspace. While the
> +vfio-pci driver does include some device specific support, further
> +extensions for yet more advanced device specific features are not
> +sustainable. The vfio-pci driver has therefore split out
> +vfio-pci-core as a library that may be reused to implement features
> +requiring device specific knowledge, ex. saving and loading device
> +state for the purposes of supporting migration.
> +
> +In support of such features, it's expected that some device specific
> +variants may interact with parent devices (ex. SR-IOV PF in support of
> +a user assigned VF) or other extensions that may not be otherwise
> +accessible via the vfio-pci base driver. Authors of such drivers
> +should be diligent not to create exploitable interfaces via such
> +interactions or allow unchecked userspace data to have an effect
> +beyond the scope of the assigned device.
> +
> +New driver submissions are therefore requested to have approval via
> +Sign-off/Acked-by/etc for any interactions with parent drivers.
> +Additionally, drivers should make an attempt to provide sufficient
> +documentation for reviewers to understand the device specific
> +extensions, for example in the case of migration data, how is the
> +device state composed and consumed, which portions are not otherwise
> +available to the user via vfio-pci, what safeguards exist to validate
> +the data, etc. To that extent, authors should additionally expect to
> +require reviews from at least one of the listed reviewers, in addition
> +to the overall vfio maintainer.
> diff --git a/Documentation/maintainer/maintainer-entry-profile.rst
> b/Documentation/maintainer/maintainer-entry-profile.rst
> index 5d5cc3acdf85..8b4971c7e3fa 100644
> --- a/Documentation/maintainer/maintainer-entry-profile.rst
> +++ b/Documentation/maintainer/maintainer-entry-profile.rst
> @@ -103,3 +103,4 @@ to do something different in the near future.
> ../nvdimm/maintainer-entry-profile
> ../riscv/patch-acceptance
> ../driver-api/media/maintainer-entry-profile
> + ../driver-api/vfio-pci-vendor-driver-acceptance
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4322b5321891..fd17d1891216 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20314,6 +20314,16 @@ F: drivers/vfio/mdev/
> F: include/linux/mdev.h
> F: samples/vfio-mdev/
>
> +VFIO PCI VENDOR DRIVERS
> +R: Jason Gunthorpe <jgg@nvidia.com>
> +R: Yishai Hadas <yishaih@nvidia.com>
> +R: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> +R: Kevin Tian <kevin.tian@intel.com>
> +L: kvm@vger.kernel.org
> +S: Maintained
> +P: Documentation/driver-api/vfio-pci-vendor-driver-acceptance.rst
> +F: drivers/vfio/pci/*/
> +
> VFIO PLATFORM DRIVER
> M: Eric Auger <eric.auger@redhat.com>
> L: kvm@vger.kernel.org
>

\
 
 \ /
  Last update: 2022-03-15 03:15    [W:0.308 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site