> From: Tian, Kevin > Sent: Monday, May 23, 2022 3:55 PM > > > From: Jacob Pan <jacob.jun....@linux.intel.com> > > +ioasid_t iommu_get_pasid_from_domain(struct device *dev, struct > > iommu_domain *domain) > > +{ > > + struct iommu_domain *tdomain; > > + struct iommu_group *group; > > + unsigned long index; > > + ioasid_t pasid = INVALID_IOASID; > > + > > + group = iommu_group_get(dev); > > + if (!group) > > + return pasid; > > + > > + xa_for_each(&group->pasid_array, index, tdomain) { > > + if (domain == tdomain) { > > + pasid = index; > > + break; > > + } > > + } > > Don't we need to acquire the group lock here? > > Btw the intention of this function is a bit confusing. Patch01 already > stores the pasid under domain hence it's redundant to get it > indirectly from xarray index. You could simply introduce a flag bit > (e.g. dma_pasid_enabled) in device_domain_info and then directly > use domain->dma_pasid once the flag is true. >
Just saw your discussion with Jason about v3. While it makes sense to not specialize DMA domain in iommu driver, the use of this function should only be that when the call chain doesn't pass down a pasid value e.g. when doing cache invalidation for domain map/unmap. If the upper interface already carries a pasid e.g. in detach_dev_pasid() iommu driver can simply verify that the corresponding pasid xarray entry points to the specified domain instead of using this function to loop xarray and then verify the returned pasid (as done in patch03/04). Thanks Kevin _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu