From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1B37C433EF for ; Fri, 11 Mar 2022 08:52:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241401AbiCKIx1 (ORCPT ); Fri, 11 Mar 2022 03:53:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240110AbiCKIx1 (ORCPT ); Fri, 11 Mar 2022 03:53:27 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4BA911BAF38 for ; Fri, 11 Mar 2022 00:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646988743; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/479Pk+vprXDZIn8pdu3Nkd2rq1k38blx/MzMekbdF8=; b=YPLrxT0Bt5T3A1FYksS3CfBLGJoAVn0/uLrwq/u2dOHxmh5aRxC+u118HAna6Tqivb6qvj tese6q57+6f8OzU0r8q+qTV3DDIZueO/VGspUZF1g+WEy45lp4DOPBOZ3KM0BQAV4b0I4s SkIRo+YijWghW5W8YVQ8DCQmdoEtF7U= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-68-0SfKBHKbMTqm_PjtgjAZ2Q-1; Fri, 11 Mar 2022 03:52:19 -0500 X-MC-Unique: 0SfKBHKbMTqm_PjtgjAZ2Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 786A5801DDC; Fri, 11 Mar 2022 08:52:17 +0000 (UTC) Received: from localhost (unknown [10.39.194.120]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7987D7369C; Fri, 11 Mar 2022 08:52:06 +0000 (UTC) From: Cornelia Huck To: Alex Williamson , "Tian, Kevin" Cc: Shameerali Kolothum Thodi , Jason Gunthorpe , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "linux-pci@vger.kernel.org" , "mgurtovoy@nvidia.com" , "yishaih@nvidia.com" , Linuxarm , liulongfang , "Zengtao (B)" , Jonathan Cameron , "Wangzhou (B)" , Xu Zaibo Subject: Re: [PATCH v8 8/9] hisi_acc_vfio_pci: Add support for VFIO live migration In-Reply-To: <20220310134954.0df4bb12.alex.williamson@redhat.com> Organization: Red Hat GmbH References: <20220303230131.2103-1-shameerali.kolothum.thodi@huawei.com> <20220303230131.2103-9-shameerali.kolothum.thodi@huawei.com> <20220304205720.GE219866@nvidia.com> <20220307120513.74743f17.alex.williamson@redhat.com> <20220307125239.7261c97d.alex.williamson@redhat.com> <20220308123312.1f4ba768.alex.williamson@redhat.com> <20220310134954.0df4bb12.alex.williamson@redhat.com> User-Agent: Notmuch/0.34 (https://notmuchmail.org) Date: Fri, 11 Mar 2022 09:52:05 +0100 Message-ID: <87tuc4hnwq.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, Mar 10 2022, Alex Williamson 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 > +L: kvm@vger.kernel.org > +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 > L: kvm@vger.kernel.org > > 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.