From: Alistair Popple <apopple@nvidia.com>
To: akpm@linux-foundation.org
Cc: ajd@linux.ibm.com, catalin.marinas@arm.com,
fbarrat@linux.ibm.com, iommu@lists.linux.dev, jgg@ziepe.ca,
jhubbard@nvidia.com, kevin.tian@intel.com, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au,
nicolinc@nvidia.com, npiggin@gmail.com, robin.murphy@arm.com,
seanjc@google.com, will@kernel.org, x86@kernel.org,
zhi.wang.linux@gmail.com, sj@kernel.org,
Alistair Popple <apopple@nvidia.com>
Subject: [PATCH v3 1/5] arm64/smmu: Use TLBI ASID when invalidating entire range
Date: Thu, 20 Jul 2023 18:39:23 +1000 [thread overview]
Message-ID: <082390057ec33969c81d49d35aa3024d7082b0bd.1689842332.git-series.apopple@nvidia.com> (raw)
In-Reply-To: <cover.b24362332ec6099bc8db4e8e06a67545c653291d.1689842332.git-series.apopple@nvidia.com>
The ARM SMMU has a specific command for invalidating the TLB for an
entire ASID. Currently this is used for the IO_PGTABLE API but not for
ATS when called from the MMU notifier.
The current implementation of notifiers does not attempt to invalidate
such a large address range, instead walking each VMA and invalidating
each range individually during mmap removal. However in future SMMU
TLB invalidations are going to be sent as part of the normal
flush_tlb_*() kernel calls. To better deal with that add handling to
use TLBI ASID when invalidating the entire address space.
Signed-off-by: Alistair Popple <apopple@nvidia.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index a5a63b1..2a19784 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -200,10 +200,20 @@ static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn,
* range. So do a simple translation here by calculating size correctly.
*/
size = end - start;
+ if (size == ULONG_MAX)
+ size = 0;
+
+ if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM)) {
+ if (!size)
+ arm_smmu_tlb_inv_asid(smmu_domain->smmu,
+ smmu_mn->cd->asid);
+ else
+ arm_smmu_tlb_inv_range_asid(start, size,
+ smmu_mn->cd->asid,
+ PAGE_SIZE, false,
+ smmu_domain);
+ }
- if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM))
- arm_smmu_tlb_inv_range_asid(start, size, smmu_mn->cd->asid,
- PAGE_SIZE, false, smmu_domain);
arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, start, size);
}
--
git-series 0.9.1
next prev parent reply other threads:[~2023-07-20 8:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 8:39 [PATCH v3 0/5] Invalidate secondary IOMMU TLB on permission upgrade Alistair Popple
2023-07-20 8:39 ` Alistair Popple [this message]
2023-07-21 19:25 ` [PATCH v3 1/5] arm64/smmu: Use TLBI ASID when invalidating entire range Jason Gunthorpe
2023-07-20 8:39 ` [PATCH v3 2/5] mmu_notifiers: Fixup comment in mmu_interval_read_begin() Alistair Popple
2023-07-21 19:26 ` Jason Gunthorpe
2023-07-20 8:39 ` [PATCH v3 3/5] mmu_notifiers: Call invalidate_range() when invalidating TLBs Alistair Popple
2023-07-21 18:25 ` Catalin Marinas
2023-07-21 19:27 ` Jason Gunthorpe
2023-07-20 8:39 ` [PATCH v3 4/5] mmu_notifiers: Don't invalidate secondary TLBs as part of mmu_notifier_invalidate_range_end() Alistair Popple
2023-07-21 19:29 ` Jason Gunthorpe
2023-07-20 8:39 ` [PATCH v3 5/5] mmu_notifiers: Rename invalidate_range notifier Alistair Popple
2023-07-21 18:25 ` Catalin Marinas
2023-07-21 19:31 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=082390057ec33969c81d49d35aa3024d7082b0bd.1689842332.git-series.apopple@nvidia.com \
--to=apopple@nvidia.com \
--cc=ajd@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=fbarrat@linux.ibm.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=nicolinc@nvidia.com \
--cc=npiggin@gmail.com \
--cc=robin.murphy@arm.com \
--cc=seanjc@google.com \
--cc=sj@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=zhi.wang.linux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox