Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>,
        Alex Williamson <alex.williamson@redhat.com>
CC:     "Liu, Yi L" <yi.l.liu@intel.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "cohuck@redhat.com" <cohuck@redhat.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "nicolinc@nvidia.com" <nicolinc@nvidia.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
        "chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
        "yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
        "peterx@redhat.com" <peterx@redhat.com>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "shameerali.kolothum.thodi@huawei.com" 
        <shameerali.kolothum.thodi@huawei.com>,
        "lulu@redhat.com" <lulu@redhat.com>,
        "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
        "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        "Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
        "joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
        "Zeng, Xin" <xin.zeng@intel.com>,
        "Zhao, Yan Y" <yan.y.zhao@intel.com>
Subject: RE: [PATCH 3/3] vfio: Report PASID capability via VFIO_DEVICE_FEATURE
 ioctl
Thread-Topic: [PATCH 3/3] vfio: Report PASID capability via
 VFIO_DEVICE_FEATURE ioctl
Thread-Index: AQHaIPx2EKyfzMrBBEWzcc+IDcJP4bCkdsqAgAAB4QCAAAr+gIABW+sAgACwu6A=
Date:   Wed, 13 Dec 2023 02:10:27 +0000
Message-ID: <BN9PR11MB52765A61C1124F75E8CEFFBC8C8DA@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20231127063909.129153-1-yi.l.liu@intel.com>
 <20231127063909.129153-4-yi.l.liu@intel.com>
 <20231211110345.1b4526c6.alex.williamson@redhat.com>
 <20231211181028.GL2944114@nvidia.com>
 <20231211114949.273b21c0.alex.williamson@redhat.com>
 <20231212153504.GL3014157@nvidia.com>
In-Reply-To: <20231212153504.GL3014157@nvidia.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2xOMnMhOUGiFm/YNMjRJsvUVj/aCgxlKt7b2a7wKqD/+ldslI6bRFTh+VwE/?=
 =?us-ascii?Q?l5OwZJpNISZVxkwdxndXQQ8ToQbGgoE9LkppkFqcJpdZfG4phDsQw9Jn+7im?=
 =?us-ascii?Q?hJxhkiI+YnCn1d9MzEyTrdT2lPfTvRxYNDi9shigDlV08egGFnVRp52NBK5s?=
 =?us-ascii?Q?u7m3gvfpZrPQsfwrHLcpwExHWGHhDT/6vwmzmOoAbQRlaFekZEwL2ihaep2H?=
 =?us-ascii?Q?mRIT3qXccUubqlL/KGVFClFTcj1/xw+5iy14QYiX+7u6hUvK+oooY2iF0+5s?=
 =?us-ascii?Q?5dd/8CXPhs2ednHcCzt+PPWL7+T/7LI8vrXfqDmwxUPJDR2Wjti4YOEVBA/e?=
 =?us-ascii?Q?2rZRVR/4bcDtGMrC6OUQv1L7j8w8+9P974L9x+MEjMszRfTq1vTPmthYesef?=
 =?us-ascii?Q?sKphrBc/OkyA/oa5y942z6PHjCfom3ThUp2UgkdzWcaK7bZULNdIKX8eS3Rs?=
 =?us-ascii?Q?pfu7tHlu2vVvFKPp7hMwPpBLuAJmKo4ZrROy85b3HX4pdPZ1GcCHoFlgjzS9?=
 =?us-ascii?Q?KzPsbQe9Vk8TrE4VLxt9VibI3D5U8L5/NWRLSQjms46j4evtZeIhKyE9nEMU?=
 =?us-ascii?Q?bAkpoM3/AiQ/drfx3ixwo8Uf3yL8SB8brTMP1pYh4iIdr3tdMXt+eUtWYWLM?=
 =?us-ascii?Q?lY3ynY1rAkHP0BL/i63cvitY8MA6om7VT3H62rVO0ECan8NnLMAOvhvRzDr9?=
 =?us-ascii?Q?A5C57FqTEQuprwcNBX18BCa6pOp8fVe3Vs8j2L77zn99Mz99q6QoTU2Oj3LG?=
 =?us-ascii?Q?Oi6KOzDxisQmrMZiGGsmUqgIgUgsq3bcH0MVLCjWf22ns1BdCFlatn1hHv5G?=
 =?us-ascii?Q?UCEn/OIuQGMl4jVPPip2LS/bqxAx+LU2GEvHSvaBaTS8nL7zvAHwc0A626zM?=
 =?us-ascii?Q?pNHt9jyC6DIrv+ydvjcjIxKFlyA60EPQeQwVNQ/KPWcu56wLuqY0Nr9mJCk1?=
 =?us-ascii?Q?bSp1J5iYngjoNXuARe8v+VGhV3+f5q2WgaRdqAvywJHlN+NxKjHAcR7jHN07?=
 =?us-ascii?Q?CxbbMcDrj1+T8wmNYkYaU930LvgD3W84K30rbqXtOW6VU8l5uH9Udq+bAbrh?=
 =?us-ascii?Q?OInJaxtqUCqjGKpFiguS6wJREeIGc5PvYcXThjveZBQT1nt6RKFoHfG54pB6?=
 =?us-ascii?Q?iDEGyaPg8fh4BO8S77jRR3qq8CS6+nQeEsGSBvY5fvXjLxeMUABQfjl87wvX?=
 =?us-ascii?Q?6sRhB5kTG3aXHTbjwLniL8OrMA+W9Ub/QGC+qJVDZz1Qu+QQ7ytwiEEkS3QM?=
 =?us-ascii?Q?zMnMjlE7a8V3EHWOINQdIBnslJwqOu3QZi8G+vY5le3oU4mOlzuNtsrYEeua?=
 =?us-ascii?Q?Ts7vpS/JERgnUA9SJVilnMjqOQ8DRKSEoF6x3iogG0/+fsccZxR48nIiPt2K?=
 =?us-ascii?Q?xF/QSHwyByKphZYLX1mESuEtdq5a4So3i2ekJfzR3suPCromfFR5oXJSZot5?=
 =?us-ascii?Q?+BMKUKL5BxiMtaV4TpHkpJ4cwbon+qU8WtuVkFO9jVhcyyRhi+nVSQe/nN38?=
 =?us-ascii?Q?mVqcEsLOyugrHsdCPToWQOn4dgc1SmTaD8KDoXDJh3YylRPxNqgmWL+o5jdn?=
 =?us-ascii?Q?S1a71RzuwzQx2v42iQyfpUycvq1OhMu6iv+cSDqu?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fd6d0178-ec71-48de-ed09-08dbfb80acf3
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2023 02:10:27.9001
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AkZVY54qaZqBfxiKJHYhCOTIgOFtWSiVCZ15y8kKxi4bK1XIS3jZSrWPwpUWoUsShj9hnjBlVlsk+Qto2m8gUw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR11MB8742
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 12 Dec 2023 18:11:15 -0800 (PST)

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Tuesday, December 12, 2023 11:35 PM
>=20
> On Mon, Dec 11, 2023 at 11:49:49AM -0700, Alex Williamson wrote:
> > On Mon, 11 Dec 2023 14:10:28 -0400
> > Jason Gunthorpe <jgg@nvidia.com> wrote:
> >
> > > On Mon, Dec 11, 2023 at 11:03:45AM -0700, Alex Williamson wrote:
> > > > On Sun, 26 Nov 2023 22:39:09 -0800
> > > > Yi Liu <yi.l.liu@intel.com> wrote:
> >
> > > > >    the PF). Creating a virtual PASID capability in vfio-pci confi=
g space
> needs
> > > > >    to find a hole to place it, but doing so may require device sp=
ecific
> > > > >    knowledge to avoid potential conflict with device specific reg=
isters
> like
> > > > >    hiden bits in VF config space. It's simpler by moving this bur=
den to
> the
> > > > >    VMM instead of maintaining a quirk system in the kernel.
> > > >
> > > > This feels a bit like an incomplete solution though and we might
> > > > already posses device specific knowledge in the form of a variant
> > > > driver.  Should this feature structure include a flag + field that
> > > > could serve to generically indicate to the VMM a location for
> > > > implementing the PASID capability?  The default core implementation
> > > > might fill this only for PFs where clearly an emualted PASID capabi=
lity
> > > > can overlap the physical capability.  Thanks,
> > >
> > > In many ways I would perfer to solve this for good by having a way to
> > > learn a range of available config space - I liked the suggestion to
> > > use a DVSEC to mark empty space.
> >
> > Yes, DVSEC is the most plausible option for the device itself to convey
> > unused config space, but that requires hardware adoption so presumably
> > we're going to need to fill the gaps with device specific code.  That
> > code might live in a variant driver or in the VMM.  If we have faith
> > that DVSEC is the way, it'd make sense for a variant driver to
> > implement a virtual DVSEC to work out the QEMU implementation and set
> a
> > precedent.
>=20
> How hard do you think it would be for the kernel to synthesize the
> dvsec if the varient driver can provide a range for it?
>=20
> On the other hand I'm not so keen on having variant drivers that are
> only doing this just to avoid a table in qemu :\ It seems like a

me too. If we really want something like this I'd prefer to tracking a
table of device specific ranges instead of requesting full-fledged
variant drivers.