[PATCH v5 22/27] iommu/arm-smmu-v3: Consolidate freeing the ASID/VMID
Jason Gunthorpe
jgg at nvidia.com
Tue Mar 19 11:37:01 PDT 2024
On Wed, Mar 20, 2024 at 12:44:42AM +0800, Michael Shavit wrote:
> On Tue, Mar 5, 2024 at 7:44 AM Jason Gunthorpe <jgg at nvidia.com> wrote:
> >
> > The SMMUv3 IOTLB is tagged with a VMID/ASID cache tag. Any time the
> > underlying translation is changed these need to be invalidated. At boot
> > time the IOTLB starts out empty and all cache tags are available for
> > allocation.
> >
> > When a tag is taken out of the allocator the code assumes the IOTLB
> > doesn't reference it, and immediately programs it into a STE/CD. If the
> > cache is referencing the tag then it will have stale data and IOMMU will
> > become incoherent.
> >
> > Thus, whenever an ASID/VMID is freed back to the allocator we need to know
> > that the IOTLB doesn't have any references to it. The SVA code correctly
> > had an invalidation here, but the paging code does not.
>
> Isn't that....bad?
Ah, that needed some more work I forgot to do.
The paging code hides the invalidation in the free_io_pgtable_ops()
called during domain free which calls back to
arm_smmu_tlb_inv_context().
free_io_pgtable_ops() is the only thing that calls
io_pgtable_tlb_flush_all() and thus arm_smmu_tlb_inv_context().
So we should also delete arm_smmu_tlb_inv_context() and NULL
ops.tlb_flush_all.
Then arm_smmu_domain_free_id() consistently handles the final
invalidation on all code paths instead of having it split up.
Thanks,
Jason
More information about the linux-arm-kernel
mailing list