Hi, Robin,
On Tue, 2018-08-14 at 11:02 +0100, Robin Murphy wrote:
> On 14/08/18 09:35, Will Deacon wrote:
> > On Tue, Aug 14, 2018 at 04:33:41PM +0800, Leizhen (ThunderTown)
> > wrote:
> > > On 2018/8/6 9:32, Yang, Shunyong wrote:
> > > > On 2018/7/26 22:37, Robin Murphy wrote:
> > > > > Because D
To support the non-strict mode, now we only tlbi and sync for the strict
mode. But for the non-leaf case, always follow strict mode.
Signed-off-by: Zhen Lei
---
drivers/iommu/io-pgtable-arm.c | 20 ++--
drivers/iommu/io-pgtable.h | 3 +++
2 files changed, 17 insertions(+), 6
.flush_iotlb_all can not just wait for previous tlbi operations to be
completed, but should also invalid all TLBs of the related domain.
Signed-off-by: Zhen Lei
Reviewed-by: Robin Murphy
---
drivers/iommu/arm-smmu-v3.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
Add a bootup option to make the system manager can choose which mode to
be used. The default mode is strict.
Signed-off-by: Zhen Lei
---
Documentation/admin-guide/kernel-parameters.txt | 13 +
drivers/iommu/arm-smmu-v3.c | 22 +-
2 files change
Dynamically choose strict or non-strict mode for page table config based
on the iommu domain type.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm-smmu-v3.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 4402187..61eb7ec 100
v4 -> v5:
1. change the type of global variable and struct member named "non_strict" from
"int" to "bool".
2. cancel the unnecessary parameter "strict" of __arm_lpae_unmap which was added
in v4.
3. change boot option "arm_iommu" to "iommu.non_strict".
4. convert __iommu_dma_unmap to use iommu
1. Save the related domain pointer in struct iommu_dma_cookie, make iovad
capable call domain->ops->flush_iotlb_all to flush TLB.
2. During the iommu domain initialization phase, base on domain->non_strict
field to check whether non-strict mode is supported or not. If so, call
init_iova_fl
On Wed, Aug 15, 2018 at 01:09:43AM +0530, Vivek Gautam wrote:
> Adding Jordan here.
>
> On Tue, Aug 14, 2018 at 4:19 PM, Robin Murphy wrote:
> > Hi Vivek,
> >
> > On 14/08/18 11:27, Vivek Gautam wrote:
> >>
> >> Add device node for qcom,smmu-v2 available on sdm845.
> >> This smmu is available onl
Adding Jordan here.
On Tue, Aug 14, 2018 at 4:19 PM, Robin Murphy wrote:
> Hi Vivek,
>
> On 14/08/18 11:27, Vivek Gautam wrote:
>>
>> Add device node for qcom,smmu-v2 available on sdm845.
>> This smmu is available only to GPU device.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> arch/arm64/boot/
On 14/08/18 11:55, Vivek Gautam wrote:
Cleanup to re-use some of the stuff
Signed-off-by: Vivek Gautam
---
drivers/iommu/arm-smmu.c | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
I think the overall diffstat would be an awful lot smaller if the
err
On 14/08/18 04:21, Ganapatrao Kulkarni wrote:
As an optimisation for PCI devices, there is always first attempt
been made to allocate iova from SAC address range. This will lead
to unnecessary attempts, when there are no free ranges
available. Adding fix to track recently failed iova address size
On 14/08/18 00:50, Logan Gunthorpe wrote:
On 13/08/18 05:48 PM, Kit Chow wrote:
On 08/13/2018 04:39 PM, Logan Gunthorpe wrote:
On 13/08/18 05:30 PM, Kit Chow wrote:
In arch/x86/include/asm/page.h, there is the following comment in
regards to validating the virtual address.
/*
* virt_to_pa
On 08/13/2018 04:50 PM, Logan Gunthorpe wrote:
On 13/08/18 05:48 PM, Kit Chow wrote:
On 08/13/2018 04:39 PM, Logan Gunthorpe wrote:
On 13/08/18 05:30 PM, Kit Chow wrote:
In arch/x86/include/asm/page.h, there is the following comment in
regards to validating the virtual address.
/*
* vir
On 14/08/2018 14:04, Robin Murphy wrote:
John raised the issue[1] that we have some unnecessary refcount contention
in the DMA ops path which shows scalability problems now that we have more
real high-performance hardware using iommu-dma. The x86 IOMMU drivers are
sidestepping this by stashing do
While iommu_get_domain_for_dev() is the robust way for arbitrary IOMMU
API callers to retrieve the domain pointer, for DMA ops domains it
doesn't scale well for large systems and multi-queue devices, since the
momentary refcount adjustment will lead to exclusive cacheline contention
when multiple C
Most parts of iommu-dma already assume they are operating on a default
domain set up by iommu_dma_init_domain(), and can be converted straight
over to avoid the refcounting bottleneck. MSI page mappings may be in
an unmanaged domain with an explicit MSI-only cookie, so retain the
non-specific looku
Whilst the symmetry of deferring to the existing sync callback in
__iommu_map_page() is nice, taking a round-trip through
iommu_iova_to_phys() is a pretty heavyweight way to get an address we
can trivially compute from the page we already have. Tweaking it to just
perform the cache maintenance dire
John raised the issue[1] that we have some unnecessary refcount contention
in the DMA ops path which shows scalability problems now that we have more
real high-performance hardware using iommu-dma. The x86 IOMMU drivers are
sidestepping this by stashing domain references in archdata, but since
that
On 8/14/2018 5:10 PM, Will Deacon wrote:
On Tue, Aug 14, 2018 at 04:25:27PM +0530, Vivek Gautam wrote:
Cleanup to re-use some of the stuff
Maybe we should factor a few of the other bits whilst we're here.
Sure, do you want me to refactor anything besides this change?
Or just write a pro
Hi Will,
On 8/14/2018 5:10 PM, Will Deacon wrote:
Hi Vivek,
On Tue, Aug 14, 2018 at 04:25:23PM +0530, Vivek Gautam wrote:
Qcom's implementation of arm,mmu-500 on sdm845 has a functional/performance
errata [1] because of which the TCU cache look ups are stalled during
invalidation cycle. This
On Tue, Aug 14, 2018 at 04:25:27PM +0530, Vivek Gautam wrote:
> Cleanup to re-use some of the stuff
Maybe we should factor a few of the other bits whilst we're here.
Or just write a proper commit message ;)
Will
___
iommu mailing list
iommu@lists.linux
Hi Vivek,
On Tue, Aug 14, 2018 at 04:25:23PM +0530, Vivek Gautam wrote:
> Qcom's implementation of arm,mmu-500 on sdm845 has a functional/performance
> errata [1] because of which the TCU cache look ups are stalled during
> invalidation cycle. This is mitigated by serializing all the invalidation
On 14/08/2018 11:45, Robin Murphy wrote:
Hi John,
Hi Robin,
On 14/08/18 11:09, John Garry wrote:
Hi All,
I have a question on function iommu_get_domain_for_dev() in DMA
mapping path, and why we need to get+put a reference to the iommu group.
The background is that we have been testing ipe
Cleanup to re-use some of the stuff
Signed-off-by: Vivek Gautam
---
drivers/iommu/arm-smmu.c | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 32e86df80428..75c146751c87 100644
--- a/dri
Qcom's implementation of arm,mmu-500 require to serialize all
TLB invalidations for context banks.
In case the TLB invalidation requests don't go through the first
time, there's a way to disable/enable the wait for safe logic.
Disabling this logic expadites the TLBIs.
Different bootloaders with th
Qcom's implementation of arm,mmu-500 on sdm845 has a functional/performance
errata [1] because of which the TCU cache look ups are stalled during
invalidation cycle. This is mitigated by serializing all the invalidation
requests coming to the smmu.
This patch series addresses this errata by adding
Qcom's smmu-500 needs to toggle wait-for-safe sequence to
handle TLB invalidation sync's.
Few firmwares allow doing that through SCM interface.
Add API to toggle wait for safe from firmware through a
SCM call.
Signed-off-by: Vivek Gautam
---
drivers/firmware/qcom_scm-32.c | 5 +
drivers/fir
There are scnenarios where drivers are required to make a
scm call in atomic context, such as in one of the qcom's
arm-smmu-500 errata [1].
[1] ("https://source.codeaurora.org/quic/la/kernel/msm-4.9/
tree/drivers/iommu/arm-smmu.c?h=msm-4.9#n4842")
Signed-off-by: Vivek Gautam
---
drivers/f
Add atomic versions of qcom_scm_io_readl/writel to enable
reading/writing secure registers from atomic context.
Signed-off-by: Vivek Gautam
---
drivers/firmware/qcom_scm-32.c | 12
drivers/firmware/qcom_scm-64.c | 32
drivers/firmware/qcom_scm.c|
Hi Vivek,
On 14/08/18 11:27, Vivek Gautam wrote:
Add device node for qcom,smmu-v2 available on sdm845.
This smmu is available only to GPU device.
Signed-off-by: Vivek Gautam
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a
Hi John,
On 14/08/18 11:09, John Garry wrote:
Hi All,
I have a question on function iommu_get_domain_for_dev() in DMA mapping
path, and why we need to get+put a reference to the iommu group.
The background is that we have been testing iperf throughput performance
for a PCIe NIC card behind
Add device node for qcom,smmu-v2 available on sdm845.
This smmu is available only to GPU device.
Signed-off-by: Vivek Gautam
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/bo
Add device node for arm,mmu-500 available on sdm845.
This MMU-500 with single TCU and multiple TBU architecture
is shared among all the peripherals except gpu on sdm845.
Signed-off-by: Vivek Gautam
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 72
1 file changed
This series enables apps-smmu (arm,mmu-500) and gpu-smmu (qcom,smmu-v2)
on sdm845. gpu-smmu needs one power domain from gpu clock controller
whose driver was sent by Amit [1].
Changes since v1:
- Addressed Rob's review comments by adding a SoC specific compatible.
Have added a new dt-bindings
Qcom's implementation of arm,mmu-500 works well with current
arm-smmu driver implementation. Adding a soc specific compatible
along with arm,mmu-500 makes the bindings future safe.
Signed-off-by: Vivek Gautam
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 5 +
1 file changed, 5 i
Hi All,
I have a question on function iommu_get_domain_for_dev() in DMA mapping
path, and why we need to get+put a reference to the iommu group.
The background is that we have been testing iperf throughput performance
for a PCIe NIC card behind an SMMUv3, with small packets and many
threads
On 14/08/18 09:35, Will Deacon wrote:
On Tue, Aug 14, 2018 at 04:33:41PM +0800, Leizhen (ThunderTown) wrote:
On 2018/8/6 9:32, Yang, Shunyong wrote:
On 2018/7/26 22:37, Robin Murphy wrote:
Because DMA code is not the only caller of iommu_map/unmap. It's
perfectly legal in the IOMMU API to part
On Tue, Aug 14, 2018 at 04:33:41PM +0800, Leizhen (ThunderTown) wrote:
> On 2018/8/6 9:32, Yang, Shunyong wrote:
> > On 2018/7/26 22:37, Robin Murphy wrote:
> >> Because DMA code is not the only caller of iommu_map/unmap. It's
> >> perfectly legal in the IOMMU API to partially unmap a previous map
On 2018/8/6 9:32, Yang, Shunyong wrote:
> Hi, Robin,
>
> On 2018/7/26 22:37, Robin Murphy wrote:
>> On 2018-07-26 8:20 AM, Leizhen (ThunderTown) wrote:
>>> On 2018/7/25 6:25, Robin Murphy wrote:
On 2018-07-12 7:18 AM, Zhen Lei wrote:
> To support the non-strict mode, now we only tlbi a
39 matches
Mail list logo