[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB5276B65B2EAF97D53719D2FE8C479@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Tue, 13 Sep 2022 03:13:58 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Lu Baolu <baolu.lu@...ux.intel.com>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>
CC: Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
"Robin Murphy" <robin.murphy@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/1] iommu/vt-d: Enable PASID during iommu device probe
> From: Lu Baolu <baolu.lu@...ux.intel.com>
> Sent: Monday, September 12, 2022 10:48 AM
>
> Previously PASID supports on both IOMMU and PCI devices are enabled in
> the
> iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) path. It's
> functionally
> correct as the SVA is the only feature that requires PASID setup. However,
> looking ahead, we will add more features that need to enable pasid (for
> example, kernel DMA with PASID, SIOV, VM guest SVA, etc.). It makes more
> sense to enable PASID during iommu probing device.
>
> This enables PASID during iommu probing device and deprecates the
> intel_iommu_enable_pasid() helper. This is safe because the IOMMU
> hardware
> will block any PCI TLP with a PASID prefix if there is no IOMMU domain
> attached to the PASID of the device.
>
IMHO it's better to enable something only when it's actually required,
e.g. does it make more sense to have a IOMMU_DEV_FEAT_PASID
instead?
What this patch does has one problem. It's an intel-iommu driver
internal policy. How can a device driver reliably tell that the pasid
capability has been enabled by the iommu driver?
Thanks
Kevin
Powered by blists - more mailing lists