On Thu, Mar 10 2022, Alex Williamson <alex.williamson@xxxxxxxxxx> wrote: > Do you think we should go so far as to formalize this via a MAINTAINERS > entry, for example: > > diff --git a/Documentation/vfio/vfio-pci-vendor-driver-acceptance.rst b/Documentation/vfio/vfio-pci-vendor-driver-acceptance.rst > new file mode 100644 > index 000000000000..54ebafcdd735 > --- /dev/null > +++ b/Documentation/vfio/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 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/MAINTAINERS b/MAINTAINERS > index 4322b5321891..4f7d26f9aac6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -20314,6 +20314,13 @@ F: drivers/vfio/mdev/ > F: include/linux/mdev.h > F: samples/vfio-mdev/ > > +VFIO PCI VENDOR DRIVERS > +R: Your Name <your.name@xxxxxxxx> > +L: kvm@xxxxxxxxxxxxxxx > +S: Maintained > +P: Documentation/vfio/vfio-pci-vendor-driver-acceptance.rst > +F: drivers/vfio/pci/*/ This works as long as the only subdirectories are for vendor drivers; should something else come up, we'd need to add an exclude statement, so no biggie. > + > VFIO PLATFORM DRIVER > M: Eric Auger <eric.auger@xxxxxxxxxx> > L: kvm@xxxxxxxxxxxxxxx > > Ideally we'd have at least Yishai, Shameer, Jason, and yourself listed > as reviewers (Connie and I are included via the higher level entry). > Thoughts from anyone? Volunteers for reviewers if we want to press > forward with this as formal acceptance criteria? Thanks, > > Alex I like having this formalized. More eyeballs are good (especially as getting good review is one of the worst bottlenecks), and I'd trust people having worked on other vendor drivers having a better grip on issues that have not been my priority.
