On Wed, Jun 07, 2023 at 12:06:07AM +0530, Michael Shavit wrote:
I suppose we also don't really have a entirely clear picture whatWhat we definately shouldn't do is try to have different SVAFwiw, this change is preserving the status-quo in that regard;
iommu_domain's pointing at the same ASID. That is again making SVA
special, which we are trying to get away from 😄
arm-smmu-v3-sva.c is already doing this. But yes, I agree that
resolving the limitation is a better long term solution... and
something I can try to look at further.
allocating multiple SVA domains should even do in the iommu driver.
The driver would like to share the ASID, but things are much cleaner
for everything if the driver model has ASID 1:1 with the iommu_domain.
It suggests we are missing some core code in iommu_sva_bind_device()
to try to re-use existing SVA iommu_domains. This would certainly be
better than trying to teach every driver how to share and refcount
its ASID concept...
Today we have this super hacky iommu_get_domain_for_dev_pasid()
thing that allows SVA domain reuse for a single device.
Possibly what we should do is conver the u32 pasid in the mm_struct to
a struct iommu_mm_data * and put alot more stuff in there. eg a linked
list of all SVA domains.