linux-stable/Documentation/driver-api/vfio-pci-device-specific-driver-acceptance.rst
Alex Williamson f621eb13fa vfio-pci: Provide reviewers and acceptance criteria for variant drivers
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.

Acked-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Yishai Hadas <yishaih@nvidia.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Acked-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/164736509088.181560.2887686123582116702.stgit@omen
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2022-03-17 09:57:11 -06:00

35 lines
1.8 KiB
ReStructuredText

.. 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 these
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/ack/review/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.