Messages in this thread | | | Date | Thu, 9 Dec 2021 11:03:23 +0000 | From | Jean-Philippe Brucker <> | Subject | Re: [PATCH 1/4] ioasid: Reserve a global PASID for in-kernel DMA |
| |
Hi Jacob,
On Tue, Dec 07, 2021 at 05:47:11AM -0800, Jacob Pan wrote: > In-kernel DMA is managed by DMA mapping APIs, which supports per device > addressing mode for legacy DMA requests. With the introduction of > Process Address Space ID (PASID), device DMA can now target at a finer > granularity per PASID + Requester ID (RID). > > However, for in-kernel DMA there is no need to differentiate between > legacy DMA and DMA with PASID in terms of mapping. DMA address mapping > for RID+PASID can be made identical to the RID. The benefit for the > drivers is the continuation of DMA mapping APIs without change. > > This patch reserves a special IOASID for devices that perform in-kernel > DMA requests with PASID. This global IOASID is excluded from the > IOASID allocator. The analogous case is PASID #0, a special PASID > reserved for DMA requests without PASID (legacy). We could have different > kernel PASIDs for individual devices, but for simplicity reasons, a > globally reserved one will fit the bill. > > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 2 +- > drivers/iommu/intel/iommu.c | 4 ++-- > drivers/iommu/intel/pasid.h | 3 +-- > drivers/iommu/intel/svm.c | 2 +- > drivers/iommu/ioasid.c | 2 ++ > include/linux/ioasid.h | 4 ++++ > 6 files changed, 11 insertions(+), 6 deletions(-) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > index ee66d1f4cb81..ac79a37ffe06 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > @@ -329,7 +329,7 @@ __arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm) > return ERR_PTR(-ENOMEM); > > /* Allocate a PASID for this mm if necessary */ > - ret = iommu_sva_alloc_pasid(mm, 1, (1U << master->ssid_bits) - 1); > + ret = iommu_sva_alloc_pasid(mm, IOASID_ALLOC_BASE, (1U << master->ssid_bits) - 1);
I'd rather keep hardware limits as parameters here. PASID#0 is reserved by the SMMUv3 hardware so we have to pass at least 1 here, but VT-d could change RID_PASID and pass 0. On the other hand IOASID_DMA_PASID depends on device drivers needs and is not needed on all systems, so I think could stay within the ioasid allocator. Could VT-d do an ioasid_alloc()/ioasid_get() to reserve this global PASID, storing it under the device_domain_lock?
This looks like we're just one step away from device drivers needing multiple PASIDs for kernel DMA so I'm trying to figure out how to evolve the API towards that. It's probably as simple as keeping a kernel IOASID set at first, but then we'll probably want to optimize by having multiple overlapping sets for each device driver (all separate from the SVA set).
Thanks, Jean
| |