From: Zhen Lei <thunder.leizhen@huawei.com>
To: Will Deacon <will.deacon@arm.com>, Joerg Roedel <joro@8bytes.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
iommu <iommu@lists.linux-foundation.org>,
Robin Murphy <robin.murphy@arm.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Cc: Zefan Li <lizefan@huawei.com>, Xinwei Hu <huxinwei@huawei.com>,
"Tianhong Ding" <dingtianhong@huawei.com>,
Hanjun Guo <guohanjun@huawei.com>,
Zhen Lei <thunder.leizhen@huawei.com>,
John Garry <john.garry@huawei.com>
Subject: [PATCH 2/5] iommu: add a new member unmap_tlb_sync into struct iommu_ops
Date: Mon, 26 Jun 2017 21:38:47 +0800 [thread overview]
Message-ID: <1498484330-10840-3-git-send-email-thunder.leizhen@huawei.com> (raw)
In-Reply-To: <1498484330-10840-1-git-send-email-thunder.leizhen@huawei.com>
An iova range may contain many pages/blocks, especially for the case of
unmap_sg. Currently, for each page/block unmapping, a tlb invalidation
operation will be followed and wait(called tlb_sync) until the operation's
over. But actually we only need one tlb_sync in the last stage. Look at
the loop in function iommu_unmap:
while (unmapped < size) {
...
unmapped_page = domain->ops->unmap(domain, iova, pgsize);
...
}
It's not a good idea to add the tlb_sync in domain->ops->unmap.
There are many profits, below actions can be reduced:
1. iommu hardware is a shared resource for cpus, for the tlb_sync operation,
lock protection is needed.
2. iommu hardware is not inside CPU, to start tlb_sync and check it finished
may take a lot of time.
Some people might ask: Is it safe to do so? The answer is yes. The standard
processing flow is:
alloc iova
map
process data
unmap
tlb invalidation and sync
free iova
What should be guaranteed is: "free iova" action is behind "unmap" and "tlbi
operation" action, that is what we are doing right now. This ensures that:
all TLBs of an iova-range have been invalidated before the iova reallocated.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/iommu.c | 3 +++
include/linux/iommu.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index cf7ca7e..01e91a8 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1610,6 +1610,9 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t size)
unmapped += unmapped_page;
}
+ if (domain->ops->unmap_tlb_sync)
+ domain->ops->unmap_tlb_sync(domain);
+
trace_unmap(orig_iova, size, unmapped);
return unmapped;
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 2cb54ad..5964121 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -197,6 +197,7 @@ struct iommu_ops {
phys_addr_t paddr, size_t size, int prot);
size_t (*unmap)(struct iommu_domain *domain, unsigned long iova,
size_t size);
+ void (*unmap_tlb_sync)(struct iommu_domain *domain);
size_t (*map_sg)(struct iommu_domain *domain, unsigned long iova,
struct scatterlist *sg, unsigned int nents, int prot);
phys_addr_t (*iova_to_phys)(struct iommu_domain *domain, dma_addr_t iova);
--
2.5.0
next prev parent reply other threads:[~2017-06-26 13:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-26 13:38 [PATCH 0/5] arm-smmu: performance optimization Zhen Lei
2017-06-26 13:38 ` [PATCH 1/5] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction Zhen Lei
2017-06-28 9:32 ` Will Deacon
2017-06-29 2:08 ` Leizhen (ThunderTown)
2017-07-17 13:06 ` John Garry
2017-07-17 14:23 ` Jonathan Cameron
2017-07-17 17:28 ` Nate Watterson
2017-07-18 9:20 ` Jonathan Cameron
2017-07-20 19:07 ` Nate Watterson
2017-07-21 10:57 ` Jonathan Cameron
2017-08-22 15:41 ` Joerg Roedel
2017-08-23 1:21 ` Leizhen (ThunderTown)
2017-06-26 13:38 ` Zhen Lei [this message]
2017-06-26 13:38 ` [PATCH 3/5] iommu/arm-smmu-v3: add support for unmap an iova range with only one tlb sync Zhen Lei
2017-06-26 13:38 ` [PATCH 4/5] iommu/arm-smmu: add support for unmap a memory " Zhen Lei
2017-06-26 13:38 ` [PATCH 5/5] iommu/io-pgtable: delete member tlb_sync_pending of struct io_pgtable Zhen Lei
2017-08-17 14:36 ` [PATCH 0/5] arm-smmu: performance optimization Will Deacon
2017-08-18 3:19 ` Leizhen (ThunderTown)
2017-08-18 8:39 ` Will Deacon
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=1498484330-10840-3-git-send-email-thunder.leizhen@huawei.com \
--to=thunder.leizhen@huawei.com \
--cc=dingtianhong@huawei.com \
--cc=guohanjun@huawei.com \
--cc=huxinwei@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=john.garry@huawei.com \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=robin.murphy@arm.com \
--cc=will.deacon@arm.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
all inboxes | Powered by JetHome®