Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Jason Gunthorpe <jgg@nvidia.com>
CC:     "Liu, Yi L" <yi.l.liu@intel.com>,
        "joro@8bytes.org" <joro@8bytes.org>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "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+IDcJP4bCdkKlggAY/u4CAATAaUIAA3hcAgACraDA=
Date:   Wed, 13 Dec 2023 01:59:26 +0000
Message-ID: <BN9PR11MB5276E0744C625273624333E08C8DA@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20231127063909.129153-1-yi.l.liu@intel.com>
 <20231127063909.129153-4-yi.l.liu@intel.com>
 <BN9PR11MB527639DBE4C433542F351F6D8C8BA@BN9PR11MB5276.namprd11.prod.outlook.com>
 <0bdae2ca-a200-4db1-a016-059730d1545e@intel.com>
 <BN9PR11MB52763C75E3D638B722CE63A78C8EA@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20231212153130.GK3014157@nvidia.com>
In-Reply-To: <20231212153130.GK3014157@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?8ZnzLuYMI3AmEObcUXalim5yyQWf9JZ0NqJnaJrTQZFi+H9AMd9lK/Y/0P+b?=
 =?us-ascii?Q?G3+DGr0J5s6+3KqCnFuh/VQit6jdnM9HkXsPKvF3tsUrGtG88fZ/Z1FeRKfD?=
 =?us-ascii?Q?6a5lKV+BuePB3NDN3TcyOgmRCEJ+paFszBCBa19hnkXfeCY1xyQuPCldLOlJ?=
 =?us-ascii?Q?v7x03/bHVSAaAJ9f+85F6VNh0Mn0NpGN0scqXCn4WbwWDE4whhYJm1vWjnvO?=
 =?us-ascii?Q?q4n0VsYAvVbp2NwV2dQ4nYR51kFdIhmFqwgryyRheODvzu0oEGexKxIC9oCN?=
 =?us-ascii?Q?vgLh6S4mnKaLo/psonSWlsV4Cp/zWI7qf7LeoeBxwW4/7PM89sTWOQbn7Wlb?=
 =?us-ascii?Q?yK7ABMcgZSTbC+E61ruHYk0/CMTDbA8Ox3KLXuc22l2G83wwLgljC0r9yhcF?=
 =?us-ascii?Q?stBA2uWpp6sxztP++stAVLmq5dNIn88+0Deog5Gm5CwFJS9KDL+n5a9giA5e?=
 =?us-ascii?Q?qkjixHO6N/sKFy57KAlz7PSF6qWvXghmG6Yq6QZKCu8OArbCyYz1AUM1q5ej?=
 =?us-ascii?Q?SOzFn8ra5M0H2HtLif7mT3Pl8clidY8mx30yO8fZZN9XSYEgoE0bVrpkwDGl?=
 =?us-ascii?Q?psmWQvLilBv8KiMx+AWAvoTCWO7rFIFiZ21G3VP8nKimeI86+muYLWev1x+A?=
 =?us-ascii?Q?FMOr5x0RhcX/h204GBaz3GOeZuVYhP2u0dmUj2AMncDyU84fbN54A8AxKgyZ?=
 =?us-ascii?Q?11O2XTqCfYSFtencQfgF0TxjhB1JeGy+DFXb7H2Cf854uFQLIoCT3Qaiyvi2?=
 =?us-ascii?Q?R55artrg9oenHbaP+PR/7czincrWbYy7trjWBZmNqXO6xFtUUU4A7jUPzqKD?=
 =?us-ascii?Q?vtoNqgtK7pbdrKHBhp2bapn4w0+dFP5ZXhyePRtsclGwovw4Sew3p8spqhdJ?=
 =?us-ascii?Q?8HeOZOMmCI9w571dQ6WPyUL108aJPs7cAvMPahQ7eFf7Ra9sbWnXc+MPZezj?=
 =?us-ascii?Q?KaR81l4giME7V7ohpOILeYYp2IIvmz9o6On5HDe3xjl8YR85yZf2vb86Hxge?=
 =?us-ascii?Q?5YUaQXkKjCwKKqHex1OvqOonmv4gWj0NaB38TjEACQJPlibWZxxbj3y97AVr?=
 =?us-ascii?Q?RoOHN7FQElIELSjdPfqh6qz+wmUbH/oYeYNBm9lpDjTCSA+tYwT75SUcnqjp?=
 =?us-ascii?Q?JXk4a1Y9b0NQIz44vxfieGyswX60x/Gvb26tXbOd7FPcifRbA4FxVUn5pEyo?=
 =?us-ascii?Q?jPB2Iexua+vev8rT4MvHGYjOazlhJNSUXNKdrwIeFweo7lKQMJzP5OpAcwSv?=
 =?us-ascii?Q?iREBkEZ6462AU4Lvhq//7Z5JRa4IYAl2ri4+y58DjW9ltLlb+TCNcBDCOm/b?=
 =?us-ascii?Q?S7wSFYhOr4POFZj9NPQEdyJflQsaPigB9sbczboKfJZenoBvSG/L2paai4if?=
 =?us-ascii?Q?UG9ylqL8R/teNskrT8JDTLfpSisaZVHtEbhjDKFc1VDzC1cMQEmR1hZUZCjB?=
 =?us-ascii?Q?jVvzQk/LPayO3rQ3u5VXKoWY1HBzyn1DzjPV7+6HrE4aMEdCW7XORvi+CMlp?=
 =?us-ascii?Q?GJhYmWq1opntlACJKPNcTig2yhzkl2pHfZ+zOq5bQc8N1RaWC82LuQmbb5RB?=
 =?us-ascii?Q?he1PYjdVrt3MPROoUSJbNuEwFjn6jwwYsrNMsEyz?=
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: 1fcb0f70-8d69-475f-d585-08dbfb7f2308
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2023 01:59:26.9638
 (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: fbdFqBR5+aS6Vo80s90oZSEkgqS0bJfy3Wl38aXlHzsOC3YF5oxD6wZ7r/sqw+9LpF8/ZQ8EmkgGqCSsgM/WZw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7852
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 17:59:43 -0800 (PST)

> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Tuesday, December 12, 2023 11:32 PM
>=20
> On Tue, Dec 12, 2023 at 02:20:01AM +0000, Tian, Kevin wrote:
> > > From: Liu, Yi L <yi.l.liu@intel.com>
> > > Sent: Monday, December 11, 2023 4:08 PM
> > >
> > > On 2023/12/7 16:47, Tian, Kevin wrote:
> > > >> From: Liu, Yi L <yi.l.liu@intel.com>
> > > >> Sent: Monday, November 27, 2023 2:39 PM
> > > >>
> > > >> +static int vfio_pci_core_feature_pasid(struct vfio_device *device=
, u32
> > > flags,
> > > >> +				       struct vfio_device_feature_pasid __user
> > > >> *arg,
> > > >> +				       size_t argsz)
> > > >> +{
> > > >> +	struct vfio_pci_core_device *vdev =3D
> > > >> +		container_of(device, struct vfio_pci_core_device, vdev);
> > > >> +	struct vfio_device_feature_pasid pasid =3D { 0 };
> > > >> +	struct pci_dev *pdev =3D vdev->pdev;
> > > >> +	u32 capabilities =3D 0;
> > > >> +	int ret;
> > > >> +
> > > >> +	/* We do not support SET of the PASID capability */
> > > >
> > > > this line alone is meaningless. Please explain the reason e.g. due =
to
> > > > no PASID capability per VF...
> > >
> > > sure. I think the major reason is we don't allow userspace to change =
the
> > > PASID configuration. is it?
> >
> > if only PF it's still possible to develop a model allowing userspace to
> > change.
>=20
> More importantly the primary purpose of setting the PASID width is
> because of the physical properties of the IOMMU HW.
>=20
> IOMMU HW that supports virtualization should do so in a way that the
> PASID with can be globally set to some value the hypervisor is aware
> the HW can decode in all cases.
>=20
> The VM should have no way to make the HW ignore (vs check for zero)
> upper bits of the PASID that would require the physical PASID bits to
> be reduced.
>=20
> So we should never allow programming of this, VMM just fakes it and
> ignores sets.

PASID width is read-only so certainly sets should be ignored

>=20
> Similar argument for enable, IOMMU HW supporting virtualization should
> always be able to decode PASID and reject PASID TLPs if the VM hasn't
> configured the vIOMMU to decode them. The purpose of the disable bit
> is to accommodate IOMMU HW that cannot decode the PASID TLP at all and
> would become confused.
>=20

Yes, this explains why disallowing userspace to change doesn't cause
problem in this series. My earlier point was just that allowing userspace
to change could be implemented for PF (though unnecessary with your
explanation) to mimic the hardware behavior.