[PATCH v2 7/9] iommu/arm-smmu-v3: Move the DMA API comment to flush_iotlb_all
Jason Gunthorpe <[email protected]>
| Newsgroups | dev.linux.lists.patches,dev.linux.lists.iommu,org.infradead.lists.linux-arm-kernel |
|---|---|
| Message-ID | <[email protected]> |
arm_smmu_tlb_inv_context() is the wrong flush_all for this comment, it is only called during io-pgtable destruction not during the dma-iommu operation. Move it to arm_smmu_flush_iotlb_all() which is the flush that is triggered by the dma-iommu lazy flush thread. Reviewed-by: Mostafa Saleh <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 31 +++++++++++---------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 22ff4aa01d208a..f2e4b66ebf1ce5 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -2457,21 +2457,6 @@ static void arm_smmu_tlb_inv_context(void *cookie) { struct arm_smmu_domain *smmu_domain = cookie; - /* - * If the DMA API is running in non-strict mode then another CPU could - * have changed the page table and not invoked any flush op. Instead the - * other CPU will do an atomic_read() and this CPU will have done an - * atomic_write(). That handshake is enough to acquire the page table - * writes from the other CPU. - * - * All command execution has a dma_wmb() to release all the in-memory - * structures written by this CPU, that barrier must also release the - * writes acquired from all the other CPUs too. - * - * There are other barriers and atomics on this path, but the above is - * the essential mechanism for ensuring that HW sees the page table - * writes from another CPU before it executes the IOTLB invalidation. - */ arm_smmu_domain_inv(smmu_domain); } @@ -4176,6 +4161,22 @@ static void arm_smmu_flush_iotlb_all(struct iommu_domain *domain) { struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); + /* + * If the DMA API is running in non-strict mode then another CPU could + * have changed the page table and not invoked any flush op. Instead the + * other CPU will do an atomic_read() and this CPU will have done an + * atomic_write(). That handshake is enough to acquire the page table + * writes from the other CPU. + * + * All command execution has a dma_wmb() to release all the in-memory + * structures written by this CPU, that barrier must also release the + * writes acquired from all the other CPUs too. + * + * There are other barriers and atomics on this path, but the above is + * the essential mechanism for ensuring that HW sees the page table + * writes from another CPU before it executes the IOTLB invalidation. + */ + if (smmu_domain->smmu) arm_smmu_tlb_inv_context(smmu_domain); } -- 2.43.0