>> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
>> IOVA accesses across them.
>> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
>> string for Tegra194 SoC SMMU topology.
>There is no description here of the 3rd SMMU that you mention below.
>I think t
>OK, well I see what you are saying, but if we intended to support all 3 for
>Tegra194, then we should ensure all 3 are initialised correctly.
The driver intend to support up to 3 instances. It doesn't really mandate that
all three instances be present in same DT node.
Each mmio aperture in "reg
>> The driver intend to support up to 3 instances. It doesn't really mandate
>> that all three instances be present in same DT node.
>> Each mmio aperture in "reg" property is an instance here. reg =
>> , , ; The reg can have
>> all three or less and driver just configures based on reg and it wo
r
two ARM MMU-500s.
This implementation supports programming two or three ARM MMU-500s
identically as per DT config.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 3 +
drivers/iommu/arm
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 98 +
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu/arm-smmu.h| 3 +
3
/lkml/2019/10/30/1054
v3 - https://lkml.org/lkml/2019/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (4):
iommu/arm-smmu: move TLB timeout and spin count macros
iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500 usage
dt
Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
.../devicetree/bindings/iommu/arm,smmu.yaml| 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.ya
Move TLB timeout and spin count macros to header file to
allow using the same values from vendor specific implementations.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c | 3 ---
drivers/iommu/arm-smmu.h | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers
>> + * When Linux kernel supports multiple SMMU devices, the SMMU device
>> +used for
>> + * isochornous HW devices should be added as a separate ARM MMU-500
>> +device
>> + * in DT and be programmed independently for efficient TLB invalidates.
>I don't understand the "When" there - the driver h
>> + - description: NVIDIA SoCs that use more than one "arm,mmu-500"
> Hmm, there must be a better way to word that to express that it only applies
> to the sets of SMMUs that must be programmed identically, and not any other
> independent MMU-500s that might also happen to be in the same So
>>> +for (inst = 0; inst < nvidia_smmu->num_inst; inst++) {
>>> +irq_ret = nvidia_smmu_global_fault_inst(irq, smmu, inst);
>>> +if (irq_ret == IRQ_HANDLED)
>>> +return irq_ret;
>>
>> Any chance there could be more than one SMMU faulting by the time we
+items:
+ - enum:
+ - nvdia,tegra194-smmu
+ - const: arm,mmu-500
> >
>>> Is the fallback compatible appropriate here? If software treats this as a
>>> standard MMU-500 it will only program the first instance (because the
>>> second isn't
>Yeah, I realised later last night that this probably originated from forking
>the whole driver downstream. But even then you could have treated the other
>one as a separate nsmmu with a single instance ;)
True, But the initial nvidia implementation had limitation that it can only
handle one in
>> With shared irq line, the context fault identification is not optimal
>> already. Reading all the context banks all the time can be additional mmio
>> read overhead. But, it may not hurt the real use cases as these happen only
>> when there are bugs.
>Right, I did ponder the idea of a whole
On 01/07/2020 20:00, Krishna Reddy wrote:
>>>>>> +items:
>>>>>> + - enum:
>>>>>> + - nvdia,tegra194-smmu
>>>>>> + - const: arm,mmu-500
>>>>
>>>>> Is the fall
U-500 instance is supported by standard
arm-smmu.c driver itself.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 3 +
drivers/iommu/arm-smmu-nvidia.c | 179
dr
/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (5):
iommu/arm-smmu: move TLB timeout and spin count macros
iommu/arm-smmu: ioremap smmu mmio region before implementation init
iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500
ioremap smmu mmio region before calling into implementation init.
This is necessary to allow mapped address available during vendor
specific implementation init.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
Add binding for NVIDIA's Tegra194 SoC SMMU.
Signed-off-by: Krishna Reddy
---
.../devicetree/bindings/iommu/arm,smmu.yaml| 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b/Documentation/devicetree/bindings/
Move TLB timeout and spin count macros to header file to
allow using the same from vendor specific implementations.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c | 3 ---
drivers/iommu/arm-smmu.h | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu
.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 99 +
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu/arm-smmu.h| 3 +
3 files changed, 117 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu
Thanks Rob. One question on setting "minItems: ". Please see below.
>> +allOf:
>> + - if:
>> + properties:
>> +compatible:
>> + contains:
>> +enum:
>> + - nvidia,tegra194-smmu
>> +then:
>> + properties:
>> +reg:
>> + minItem
>On Mon, Jul 13, 2020 at 02:50:20PM +0100, Will Deacon wrote:
>> On Tue, Jul 07, 2020 at 10:00:12PM -0700, Krishna Reddy wrote:
> >> Changes in v10:
>> > Perform SMMU base ioremap before calling implementation init.
>> > Check for Global faults across both
Move TLB timeout and spin count macros to header file to
allow using the same from vendor specific implementations.
Reviewed-by: Jon Hunter
Reviewed-by: Nicolin Chen
Reviewed-by: Pritesh Raithatha
Reviewed-by: Robin Murphy
Reviewed-by: Thierry Reding
Signed-off-by: Krishna Reddy
Reding
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index cdd15ead9bc4..de520115d3df 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
.
Reviewed-by: Jon Hunter
Reviewed-by: Nicolin Chen
Reviewed-by: Pritesh Raithatha
Reviewed-by: Robin Murphy
Reviewed-by: Thierry Reding
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 99 +
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu
/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (5):
iommu/arm-smmu: move TLB timeout and spin count macros
iommu/arm-smmu: ioremap smmu mmio region before implementation init
iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500 usage
dt-bindings: arm-smmu: add
Add binding for NVIDIA's Tegra194 SoC SMMU.
Reviewed-by: Jon Hunter
Reviewed-by: Rob Herring
Reviewed-by: Robin Murphy
Signed-off-by: Krishna Reddy
---
.../devicetree/bindings/iommu/arm,smmu.yaml | 25 ++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --
U-500 instance is supported by standard
arm-smmu.c driver itself.
Reviewed-by: Jon Hunter
Reviewed-by: Nicolin Chen
Reviewed-by: Pritesh Raithatha
Reviewed-by: Robin Murphy
Reviewed-by: Thierry Reding
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Mak
Tested-by: Krishna Reddy
> 1) pass the guest stage 1 configuration
Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM along
with patch series "v11 SMMUv3 Nested Stage Setup (VFIO part)" and QEMU patch
series "vSMMUv3/pSMMUv3 2 stage VFIO integration&q
Tested-by: Krishna Reddy
> 1) pass the guest stage 1 configuration
> 3) invalidate stage 1 related caches
Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM along
with patch series "v13 SMMUv3 Nested Stage Setup (IOMMU part)" and QEMU patch
series "vS
> Hi Krishna,
> On 3/15/21 7:04 PM, Krishna Reddy wrote:
> > Tested-by: Krishna Reddy
> >
> >> 1) pass the guest stage 1 configuration
> >
> > Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM
> along with patch series "v11 SM
Tested-by: Krishna Reddy
Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM and is
functional.
This patch series resolved the mismatch(seen with v11 patches) for
VFIO_IOMMU_SET_PASID_TABLE and VFIO_IOMMU_CACHE_INVALIDATE Ioctls between linux
and QEMU patch series
Tested-by: Krishna Reddy
Validated nested translations with NVMe PCI device assigned to Guest VM.
Tested with both v12 and v13 of Jean-Philippe's patches as base.
> This is based on Jean-Philippe's
> [PATCH v12 00/10] iommu: I/O page faults for SMMUv3
> https://lore.kernel.o
Tested-by: Krishna Reddy
Validated v13 patches in context of nested translations validation for NVMe
PCIe device assigned to Guest VM.
V12 patches(v13 is yet to be tested) has been tested for SVA functionality on
Native OS and is functional.
-KR
>+static const struct arm_smmu_impl nvidia_smmu_single_impl = {
>+ .probe_finalize = nvidia_smmu_probe_finalize,
>+};
nvidia_smmu_probe_finalize is used before it is defined. It is defined in patch
5.
-KR
___
iommu mailing list
iommu@lists.linux-
>> Did that patch cause any issue, or is it just not needed on your system?
>> It fixes an hypothetical problem with the way ATS is implemented.
>> Maybe I actually observed it on an old software model, I don't
>> remember. Either way it's unlikely to go upstream but I'd like to know
>> if I sho
> Is it always safe to enable SMMU ASID in a middle of a DMA request made by a
> memory client?
>From MC point of view, It is safe to enable and has been this way from many
>years in downstream code for display engine.
It doesn't impact the transactions that have already bypassed SMMU before
ena
Hi Dmitry,
> Thank you for the answer. Could you please give more information about:
> 1) Are you on software or hardware team, or both?
I am in the software team and has contributed to initial Tegra SMMU driver in
the downstream along with earlier team member Hiroshi Doyu.
> 2) Is SMMU a third
> > No, the unmap latency is not just in some test case written, the issue
> > is very real and we have workloads where camera is reporting frame
> > drops because of this unmap latency in the order of 100s of milliseconds.
> > And hardware team recommends using ASID based invalidations for
> > any
Hi Sai,
> >> > No, the unmap latency is not just in some test case written, the
> >> > issue is very real and we have workloads where camera is reporting
> >> > frame drops because of this unmap latency in the order of 100s of
> milliseconds.
> Not exactly, this issue is not specific to camera. If
> > + mutex_lock(&group->mutex);
> > iommu_alloc_default_domain(group, dev);
> > + mutex_unlock(&group->mutex);
>
> It feels wrong to serialise this for everybody just to cater for systems with
> aliasing SIDs between devices.
Serialization is limited to devices in the same group. U
> Right but we won't know until we profile the specific usecases or try them in
> generic workload to see if they affect the performance. Sure, over
> invalidation is
> a concern where multiple buffers can be mapped to same context and the cache
> is not usable at the time for lookup and such but
> if (smmu->impl->probe_finalize)
The above is the issue. It should be updated as below similar to other
instances impl callbacks.
if (smmu->impl && smmu->impl->probe_finalize)
-KR
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.
> Instead of flush_ops in init_context hook, perhaps a io_pgtable quirk since
> this is
> related to tlb, probably a bad name but IO_PGTABLE_QUIRK_TLB_INV which will
> be set in init_context impl hook and the prev condition in
> io_pgtable_tlb_flush_walk()
> becomes something like below. Seems ver
> +
> +err_pm_disable:
> + pm_runtime_disable(dev);
> return ret;
> }
Should it be pm_runtime_force_suspend()? qcom_iommu_device_remove() doesn't
use pm_runtime_disable(dev).
875 static int qcom_iommu_device_remove(struct platform_device *pdev)
876 {
...
881 >---pm_runtime_
Hi Jean,
> > Why is BTM mandated for SVA? I couldn't find this requirement in
> > SMMU spec (Sorry if I missed it or this got discussed earlier). But
> > if performance is the
> only concern here,
> > is it better just to allow it with a warning rather than limiting
> > SMMUs without
> BTM?
>
>
> > The Tegra Next Generation SOC uses arm-smmu-v3, but it doesn't have support
> > for BTM.
> > Do you have plan to get your earlier patch to handle invalidate
> > notifications into upstream sometime soon?
>Is that a limitation of the SMMU implementation, the interconnect or the
>integration?
>> The Tegra Next Generation SOC uses arm-smmu-v3, but it doesn't have support
>> for BTM.
>> Do you have plan to get your earlier patch to handle invalidate
>> notifications into upstream sometime soon?
>> Can the dependency on BTM be relaxed with the patch?
>>
>> PATCH v9 13/13] iommu/arm-smmu-
Hi Jean,
> +bool arm_smmu_master_sva_supported(struct arm_smmu_master *master) {
> + if (!(master->smmu->features & ARM_SMMU_FEAT_SVA))
> + return false;
+
> + /* SSID and IOPF support are mandatory for the moment */
> + return master->ssid_bits && arm_smmu_iopf_sup
> I agree that we should let a device driver enable SVA if it supports some
> form of IOPF.
Right, The PCIe device has capability to handle IO page faults on its own when
ATS translation request response indicates that no valid mapping exist.
SMMU doesn't involve/handle page faults for ATS tra
t; .probe_finalize = nvidia_smmu_probe_finalize,
> + .init_context = nvidia_smmu_init_context,
> };
>
> static const struct arm_smmu_impl nvidia_smmu_single_impl = {
> .probe_finalize = nvidia_smmu_probe_finalize,
> + .init_context = nvidia_smmu_init_context,
> };
>
Reviewed-by: Krishna Reddy
-KR
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Good effort to isolate bus config from smmu drivers.
Reviewed-By: Krishna Reddy
I have an orthogonal question here.
Can the following code handle the case, where different buses have different
type of SMMU instances(like one bus has SMMUv2 and another bus has SMMUv3)?
If it need to handle the
Hi Eric,
> This is based on Jean-Philippe's
> [PATCH v14 00/10] iommu: I/O page faults for SMMUv3
> https://www.spinics.net/lists/arm-kernel/msg886518.html
> (including the patches that were not pulled for 5.13)
>
Jean's patches have been merged to v5.14.
Do you anticipate IOMMU/VFIO part patches
101 - 154 of 154 matches
Mail list logo
