On Mon, Dec 11, 2023 at 12:11:25PM -0800, Nicolin Chen wrote: > On Mon, Dec 11, 2023 at 09:20:41AM -0400, Jason Gunthorpe wrote: > > On Mon, Dec 11, 2023 at 08:35:09PM +0800, Yi Liu wrote: > > > > So.. In short.. Invalidation is a PITA. The idea is the same but > > > > annoying little details interfere with actually having a compltely > > > > common API here. IMHO the uAPI in this series is fine. It will support > > > > Intel invalidation and non-ATC invalidation on AMD/ARM. It should be > > > > setup to allow that the target domain object can be any HWPT. > > > > > > This HWPT is still nested domain. Is it? But it can represent a guest I/O > > > page table (VT-d), guest CD table (ARM), guest CR3 Table (AMD, it seems to > > > be a set of guest CR3 table pointers). May ARM and AMD guys keep me honest > > > here. > > > > I was thinking ARM would not want to use a nested domain because > > really the invalidation is global to the entire nesting parent. > > > > But, there is an issue with that - the nesting parent could be > > attached to multiple iommu instances but we only want to invalidate a > > single instance. > > I am still not sure about attaching an S2 domain to multiple > SMMUs. An S2 domain is created per SMMU, and we have such a > rejection in arm_smmu_attach_dev(): > } else if (smmu_domain->smmu != smmu) > ret = -EINVAL; I intend to remove that eventually > I understand that it would be probably ideal to share the S2 > iopt among the SMMUs. But in the driver the objects (domain) > holding a shared S2 iopt must be different to allocate their > own VMIDs, right? No, the vmid will be moved into the struct arm_smmu_master_domain Jason