Messages in this thread | | | From | Michael Shavit <> | Date | Thu, 11 May 2023 11:52:41 +0800 | Subject | Re: [PATCH v1 0/5] Add PASID support to SMMUv3 unmanaged domains |
| |
> Logically when an iommu_domain is attached to a device or a PASID a > STE or CD is generated from the iommu_domain's configuration but the > iommu_domain doesn't "hold" it >
Ah yes, I was using iommu domain and arm_smmu_domain interchangeably here since there's a 1:1 mapping between the two. In the current smmuv3 implementation, arm_smmu_domain holds the s1cfg structure which represents the s1 portion of an STE.
> I always thought of this as sort of a pre-calculation of the STE, that > gets cached in the iommu_domain? Not sure the pre-calculation is that > valuable though..
I think we can consider the case where an iommu domain is attached to multiple masters as a form of pre-calculation and resource sharing. When attaching an iommu domain that has been attached before, its arm_smmu_domain contains an already finalized STE configuration that can be immediately written to the smmu. I don't think there's anything specific to SVA about this behavior however, SVA will do the same amount of work whether the cd table is owned by some special iommu domain or by the arm_smmu_master (since we require that special iommu domain be attached to the master and disallow detaching it).
> Ideally the iommu_domain should only hold a pointer to some table top. Depending on the domain type this would be a S1 IOPTE table, S2 IOPTE table or a CD table. Plus the non-table domains like IDENTITY and blocked.
Gotcha. So this patch series should be less aggressive, but is probably still workable with the nested domain patch series: 1. For (stage 1) unmanaged/dma and sva domains, arm_smmu_domains should hold a single CD. For the nested domain series, arm_smmu_domain can alternatively hold an entire s1cfg. 2. arm_smmu_master should own an s1cfg (which holds a cdtable) that is used by unmanaged/dma and sva domains attached to this master. 3. arm_smmu_master also holds a pointer to the live s1cfg, which may either points to its owned s1cfg, or the nested domain's s1cfg, or null (bypass or stage2)
> > path forward for set_dev_pasid support? Or could a uAPI that only > > exposes a single CD instead of the entire STE be an appropriate fit for > > the nesting use cases? > > The uAPI is to create an iommu_domain that holds a CD Table Top > located in user memory, it cannot deviate from this. These kinds of > iommu_domain's can only be pointed at by STEs. > > Again it doesnt really "hold" the STE, but we can compute a STE that > points to the SD Table that it does hold. > > Other than this, it is good to take this project on, getting PASID > support aligned with the new API is something that needs to be done > here! > > Thanks, > Jason
| |