[PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs

[PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs

[Vikash Garodia]

Qualcomm venus and iris VPUs reserve IOVA addresses below 0x25800000 
(600MB) for non-pixel stream ID in secure mode. When the kernel 
allocates DMA mappings from this restricted range, the VPU generate 
unhandled SMMU page faults, leading to video failures and, in some 
cases, spontaneous system reboots.
 
The issue is readily reproducible on affected platforms by running
multiple concurrent video decode workloads, such as opening several
browser tabs containing video streams.

To prevent allocations in the restricted region, this series introduces
support for an IOMMU IOVA reserve memory-region in the Venus and Iris
bindings and updates all affected device trees to reserve the low IOVA
range [0, 0x25800000]. The memory-region is referenced by the video codec
node, allowing the IOMMU layer to keep DMA allocations above the reserved
boundary.
 
The series consists of:
 
  * Binding updates for Venus and Iris schemas to permit an additional
    memory-region phandle describing the IOVA reservation.
  * DTS updates for all affected Venus platforms.
  * DTS updates for all affected Iris platforms.
 
This ensures that DMA allocations do not overlap restricted IOVA
mappings for non-pixel stream IDs and prevents the resulting SMMU
faults.

Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
Daniel J Blueman (2):
      dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region
      arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

Vikash Garodia (20):
      dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region
      dt-bindings: media: qcom,sc7180-venus: Allow IOVA reservation memory-region
      arm64: dts: qcom: lemans: Reserve low IOVA range for Iris
      arm64: dts: qcom: monaco: Reserve low IOVA range for Iris
      arm64: dts: qcom: sc8280xp: Reserve low IOVA range for Iris
      arm64: dts: qcom: sm8350: Reserve low IOVA range for Iris
      arm64: dts: qcom: sm8550: Reserve low IOVA range for Iris
      arm64: dts: qcom: sm8650: Reserve low IOVA range for Iris
      arm64: dts: qcom: sm8750: Reserve low IOVA range for Iris
      arm64: dts: qcom: agatti: Reserve low IOVA range for Venus
      arm64: dts: qcom: kodiak: Reserve low IOVA range for Venus
      arm64: dts: qcom: msm8916: Reserve low IOVA range for Venus
      arm64: dts: qcom: msm8996: Reserve low IOVA range for Venus
      arm64: dts: qcom: msm8998: Reserve low IOVA range for Venus
      arm64: dts: qcom: sc7180: Reserve low IOVA range for Venus
      arm64: dts: qcom: sdm630: Reserve low IOVA range for Venus
      arm64: dts: qcom: sdm845: Reserve low IOVA range for Venus
      arm64: dts: qcom: sm6115: Reserve low IOVA range for Venus
      arm64: dts: qcom: sm8250: Reserve low IOVA range for Venus
      arm64: dts: qcom: talos: Reserve low IOVA range for Venus

 .../devicetree/bindings/media/qcom,sc7180-venus.yaml       |  5 ++++-
 .../devicetree/bindings/media/qcom,sm8550-iris.yaml        |  5 ++++-
 .../devicetree/bindings/media/qcom,venus-common.yaml       |  5 ++++-
 arch/arm64/boot/dts/qcom/agatti.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/hamoa.dtsi                        | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/kodiak.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/lemans.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/monaco.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/msm8916.dtsi                      | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/msm8996.dtsi                      | 14 +++++++++++++-
 arch/arm64/boot/dts/qcom/msm8998.dtsi                      | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/qcs8550.dtsi                      | 11 +++++++++++
 arch/arm64/boot/dts/qcom/sc7180.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/sc8280xp.dtsi                     | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/sdm630.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/sdm845.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/sm6115.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/sm8250.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/sm8350.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/sm8550.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/sm8650.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/sm8750.dtsi                       | 13 ++++++++++++-
 arch/arm64/boot/dts/qcom/talos.dtsi                        | 13 ++++++++++++-
 23 files changed, 252 insertions(+), 22 deletions(-)
---
base-commit: 1701fda2f58e345c050f4309971bdc07cd6146ba
change-id: 20260807-iris_iova_600mb_fix-70f6ca25896d

Best regards,
-- 
Vikash Garodia <vikash.garodia@oss.qualcomm.com>

[PATCH 01/22] dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region

[Vikash Garodia]

Non-pixel stream IDs should not allocate IOVA space from the 0 to 600MB
restricted region, as this region is reserved exclusively for secure
non-pixel.

In addition to the firmware-loaded codec carveout, platforms need to
declare an IOMMU IOVA reservation (a reserved-memory node with
iommu-addresses) to keep DMA away from restricted IOVA range.

Permit a second memory-region phandle for this purpose, and describe the
meaning of each entry so the ordering is unambiguous.

Fixes: f8cc21d454c5 ("media: dt-bindings: qcom,venus: split common properties")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/media/qcom,venus-common.yaml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
index 59a3fde846d2196ab1e4588eb396012ba6860712..0be2f9119e78233928d23af86836ac294aa769ee 100644
--- a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
@@ -37,7 +37,10 @@ properties:
     maxItems: 20
 
   memory-region:
-    maxItems: 1
+    minItems: 1
+    items:
+      - description: Firmware-loaded codec carveout
+      - description: IOMMU IOVA reservation region
 
   power-domains:
     minItems: 1

-- 
2.34.1

[PATCH 02/22] dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region

[Vikash Garodia]

From: Daniel J Blueman <daniel@quora.org>

Non-pixel stream IDs should not allocate IOVA space from the 0 to 600MB
restricted region, as this region is reserved exclusively for secure
non-pixel.

In addition to the firmware-loaded codec carveout, Iris platforms need
to declare an IOMMU IOVA reservation (a reserved-memory node with
iommu-addresses) to keep DMA away from restricted IOVA range.

Permit a second memory-region phandle for this purpose, and describe
the meaning of each entry so the ordering is unambiguous.

Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel J Blueman <daniel@quora.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
index 0400ca1bff05dcef6b742c3fbf77e38adca9f280..7dff7293fd5c834b0ea617ece87ffbf0d40e821a 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
@@ -84,7 +84,10 @@ properties:
   dma-coherent: true
 
   memory-region:
-    maxItems: 1
+    minItems: 1
+    items:
+      - description: Firmware-loaded codec carveout
+      - description: IOMMU IOVA reservation region
 
   operating-points-v2: true
 

-- 
2.34.1

[PATCH 03/22] dt-bindings: media: qcom,sc7180-venus: Allow IOVA reservation memory-region

[Vikash Garodia]

Non-pixel stream IDs should not allocate IOVA space from the 0 to 600MB
restricted region, as this region is reserved exclusively for secure
non-pixel.

In addition to the firmware-loaded codec carveout, platforms need to
declare an IOMMU IOVA reservation (a reserved-memory node with
iommu-addresses) to keep DMA away from restricted IOVA range.

Permit a second memory-region phandle for this purpose, and describe the
meaning of each entry so the ordering is unambiguous.

Fixes: 545d984cc90c ("media: dt-bindings: media: venus: Add sc7180 DT schema")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
index b21bed314848480b82153e49602f0b19e08e7335..52de5a5465b0f0b245b55eac6cd1acf16a00f7cf 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -51,7 +51,10 @@ properties:
     maxItems: 1
 
   memory-region:
-    maxItems: 1
+    minItems: 1
+    items:
+      - description: Firmware-loaded codec carveout
+      - description: IOMMU IOVA reservation region
 
   interconnects:
     maxItems: 2

-- 
2.34.1

[PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

[Vikash Garodia]

From: Daniel J Blueman <daniel@quora.org>

On X1-family hamoa platforms, the Iris VPU reserves IOVA addresses
below 0x25800000 (600MB), primarily for secure non-pixel buffers. DMA
into that range, from any other stream id would triggers unhandled SMMU
page faults that cause spontaneous device reboots. This is readily
reproduced with one or more browser tabs driving multiple concurrent
video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the Iris node so the IOMMU layer keeps DMA
allocations above that boundary.

Link: https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574
Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel J Blueman <daniel@quora.org>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/hamoa.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 8a96ea1bdb9c4c409b2af997680d8c13fed0643e..87f424765d513c97b06303bceb75ca9f176d2ace 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -666,6 +666,17 @@ smem_mem: smem@ffe00000 {
 			hwlocks = <&tcsr_mutex 3>;
 			no-map;
 		};
+
+		/*
+		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		iris_iova: iris-iova {
+			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	qup_opp_table_100mhz: opp-table-qup100mhz {
@@ -5439,7 +5450,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			interconnect-names = "cpu-cfg",
 					     "video-mem";
 
-			memory-region = <&video_mem>;
+			memory-region = <&video_mem>, <&iris_iova>;
 
 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
 			reset-names = "bus";

-- 
2.34.1

[PATCH 05/22] arm64: dts: qcom: lemans: Reserve low IOVA range for Iris

[Vikash Garodia]

Iris VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the Iris node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 7bc95052c64f ("arm64: dts: qcom: sa8775p: add support for video node")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/lemans.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 695eae1b7256911e656ab1ecdd92aca135d92f39..da0326fe244850f92e080e648722b4aa0037da7b 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -862,6 +862,17 @@ cpucp_fw_mem: cpucp-fw@db200000 {
 			reg = <0x0 0xdb200000 0x0 0x100000>;
 			no-map;
 		};
+
+		/*
+		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		iris_iova: iris-iova {
+			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -4957,7 +4968,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			interconnect-names = "cpu-cfg",
 					     "video-mem";
 
-			memory-region = <&pil_video_mem>;
+			memory-region = <&pil_video_mem>, <&iris_iova>;
 
 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
 			reset-names = "bus";

-- 
2.34.1

[PATCH 06/22] arm64: dts: qcom: monaco: Reserve low IOVA range for Iris

[Vikash Garodia]

Iris VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the Iris node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: bf6ec39c3f36 ("arm64: dts: qcom: qcs8300: add video node")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/monaco.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index cfe39f923224f6c9af0a1b15a84f2fefb90d53d5..048b4490fcafd292e4f8ad7f661121430f9ceb24 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -812,6 +812,17 @@ video_mem: video-region@9be82000 {
 			reg = <0x0 0x9be82000 0x0 0x700000>;
 			no-map;
 		};
+
+		/*
+		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		iris_iova: iris-iova {
+			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -5399,7 +5410,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			interconnect-names = "cpu-cfg",
 					     "video-mem";
 
-			memory-region = <&video_mem>;
+			memory-region = <&video_mem>, <&iris_iova>;
 
 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
 			reset-names = "bus";

-- 
2.34.1

[PATCH 07/22] arm64: dts: qcom: sc8280xp: Reserve low IOVA range for Iris

[Vikash Garodia]

Iris VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the Iris node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 3a52eef16b97 ("arm64: dts: qcom: sc8280xp: Add Iris core")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index fbcfd3883bbb4e465a71e60a2e295f9a4b3c668f..1c624683d003361773b5cd1e95424990e8130b9f 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -669,6 +669,17 @@ reserved-region@aeb00000 {
 			reg = <0 0xaeb00000 0 0x16600000>;
 			no-map;
 		};
+
+		/*
+		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		iris_iova: iris-iova {
+			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -4266,7 +4277,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 
 			operating-points-v2 = <&iris_opp_table>;
 			iommus = <&apps_smmu 0x2a00 0x400>;
-			memory-region = <&pil_video_mem>;
+			memory-region = <&pil_video_mem>, <&iris_iova>;
 
 			status = "disabled";
 

-- 
2.34.1

[PATCH 08/22] arm64: dts: qcom: sm8350: Reserve low IOVA range for Iris

[Vikash Garodia]

Iris VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the Iris node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: a2b0c5eba743 ("arm64: dts: qcom: sm8350: add Iris device")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index 32b47f5ec1f6755dfe9eb92df9c03e5fc2c992bb..b376dda0ed5208633660cc3b975cee738134b758 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -553,6 +553,17 @@ removed_mem: memory@d8800000 {
 			reg = <0x0 0xd8800000 0x0 0x6800000>;
 			no-map;
 		};
+
+		/*
+		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		iris_iova: iris-iova {
+			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -2786,7 +2797,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 
 			operating-points-v2 = <&iris_opp_table>;
 			iommus = <&apps_smmu 0x2100 0x400>;
-			memory-region = <&pil_video_mem>;
+			memory-region = <&pil_video_mem>, <&iris_iova>;
 
 			status = "disabled";
 

-- 
2.34.1

[PATCH 09/22] arm64: dts: qcom: sm8550: Reserve low IOVA range for Iris

[Vikash Garodia]

Iris VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the Iris node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 41661853ae8e ("arm64: dts: qcom: sm8550: add iris DT node")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/qcs8550.dtsi | 11 +++++++++++
 arch/arm64/boot/dts/qcom/sm8550.dtsi  | 13 ++++++++++++-
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs8550.dtsi b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
index f0acdd0b1e9384e684a90f7f49cf63633cd70d53..4306ce69b83da9ef5d80309d5617d723947dc796 100644
--- a/arch/arm64/boot/dts/qcom/qcs8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs8550.dtsi
@@ -158,5 +158,16 @@ mpss_dsm_mem: mpss-dsm-region@d4d00000 {
 			reg = <0x0 0xd4d00000 0x0 0x3300000>;
 			no-map;
 		};
+
+		/*
+		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		iris_iova: iris-iova {
+			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 };
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 0e701e709235c6e0a5efd7f8447dfa6ef6f6e21f..1eb725a584b26bc11dbc34eeeebf91d3131a916f 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -1088,6 +1088,17 @@ hyp_ext_reserved_mem: hyp-ext-reserved-region@ff700000 {
 			reg = <0 0xff700000 0 0x100000>;
 			no-map;
 		};
+
+		/*
+		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		iris_iova: iris-iova {
+			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -3686,7 +3697,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			interconnect-names = "cpu-cfg",
 					     "video-mem";
 
-			memory-region = <&video_mem>;
+			memory-region = <&video_mem>, <&iris_iova>;
 
 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
 			reset-names = "bus";

-- 
2.34.1

[PATCH 10/22] arm64: dts: qcom: sm8650: Reserve low IOVA range for Iris

[Vikash Garodia]

Iris VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the Iris node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 56cf5ad39a55 ("arm64: dts: qcom: sm8650: add iris DT node")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8650.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index b679fd8afb7d533f2ca42316cea6fb34997feb75..97bc56bb61caed0547fa377406f4dc3180bb22d2 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -1905,6 +1905,17 @@ llcc_lpi_mem: llcc-lpi@ff800000 {
 			reg = <0 0xff800000 0 0x600000>;
 			no-map;
 		};
+
+		/*
+		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		iris_iova: iris-iova {
+			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -5266,7 +5277,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			interconnect-names = "cpu-cfg",
 					     "video-mem";
 
-			memory-region = <&video_mem>;
+			memory-region = <&video_mem>, <&iris_iova>;
 
 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>,
 				 <&videocc VIDEO_CC_XO_CLK_ARES>,

-- 
2.34.1

[PATCH 11/22] arm64: dts: qcom: sm8750: Reserve low IOVA range for Iris

[Vikash Garodia]

Iris VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the Iris node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: c0d11ff90475 ("arm64: dts: qcom: sm8750: Add Iris VPU v3.5")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8750.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index dd738d13df8e04b0302c4b4d7ab21e318a9560a0..cf17c76a4a390b5f001bc566a2b96e30054f7da0 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -562,6 +562,17 @@ adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
 			size = <0x0 0xc00000>;
 			reusable;
 		};
+
+		/*
+		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		iris_iova: iris-iova {
+			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -2970,7 +2981,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 
 			interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 
-			memory-region = <&video_mem>;
+			memory-region = <&video_mem>, <&iris_iova>;
 
 			operating-points-v2 = <&iris_opp_table>;
 

-- 
2.34.1

[PATCH 12/22] arm64: dts: qcom: agatti: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 7a37bf31e3a7 ("arm64: dts: qcom: qcm2290: Add Venus video node")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/agatti.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/agatti.dtsi b/arch/arm64/boot/dts/qcom/agatti.dtsi
index 590bd2432d85ba80891ed42df8afa317c869daa2..6ae66ef882363a2b5b529a23429dc1f2820b2086 100644
--- a/arch/arm64/boot/dts/qcom/agatti.dtsi
+++ b/arch/arm64/boot/dts/qcom/agatti.dtsi
@@ -381,6 +381,17 @@ rmtfs_mem: memory@89b01000 {
 			qcom,client-id = <1>;
 			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA QCOM_SCM_VMID_NAV>;
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -2486,7 +2497,7 @@ venus: video-codec@5a00000 {
 				      "vcodec0_core",
 				      "vcodec0_bus";
 
-			memory-region = <&pil_video_mem>;
+			memory-region = <&pil_video_mem>, <&venus_iova>;
 			iommus = <&apps_smmu 0x860 0x0>,
 				 <&apps_smmu 0x880 0x0>;
 

-- 
2.34.1

[PATCH 13/22] arm64: dts: qcom: kodiak: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 37613aee2179 ("arm64: dts: qcom: sc7280: Add venus DT node")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kodiak.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index f2da3706d5c887e36a55dc5e2f63dc21e940191c..8894149a3d4e238dcb996e25379892949f7302e8 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -198,6 +198,17 @@ adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
 			alignment = <0x0 0x400000>;
 			size = <0x0 0x800000>;
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	cpus {
@@ -5026,7 +5037,7 @@ venus: video-codec@aa00000 {
 			interconnect-names = "cpu-cfg", "video-mem";
 
 			iommus = <&apps_smmu 0x2180 0x20>;
-			memory-region = <&video_mem>;
+			memory-region = <&video_mem>, <&venus_iova>;
 
 			status = "disabled";
 

-- 
2.34.1

[PATCH 14/22] arm64: dts: qcom: msm8916: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 16bd6c8205ac ("arm64: dts: qcom: msm8916: Add Venus video codec support")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index e39743e22043894955fddc17f04ed859fede5aa9..b9f63d9f2c775da210e8552c530f4ce47341c53c 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -114,6 +114,17 @@ mba_mem: mba {
 			no-map;
 			status = "disabled";
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x25800000>;
+		};
 	};
 
 	clocks {
@@ -1834,7 +1845,7 @@ venus: video-codec@1d00000 {
 				 <&gcc GCC_VENUS0_AXI_CLK>;
 			clock-names = "core", "iface", "bus";
 			iommus = <&apps_iommu 5>;
-			memory-region = <&venus_mem>;
+			memory-region = <&venus_mem>, <&venus_iova>;
 			status = "disabled";
 		};
 

-- 
2.34.1

[PATCH 15/22] arm64: dts: qcom: msm8996: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 902d97a44211 ("arm64: dts: qcom: msm8996: Revamp reserved memory")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 818e5660df91d9bae0c3077f476b50a28f2baee4..e8a01b4d0c462f51ff4b40af7ea1665f2e231699 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -592,6 +592,18 @@ mdata_mem: mpss-metadata {
 			size = <0x0 0x4000>;
 			no-map;
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x25800000>;
+		};
+
 	};
 
 	smem {
@@ -2427,7 +2439,7 @@ venus: video-codec@c00000 {
 				 <&venus_smmu 0x2c>,
 				 <&venus_smmu 0x2d>,
 				 <&venus_smmu 0x31>;
-			memory-region = <&venus_mem>;
+			memory-region = <&venus_mem>, <&venus_iova>;
 			status = "disabled";
 
 			video-decoder {

-- 
2.34.1

[PATCH 16/22] arm64: dts: qcom: msm8998: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 1c6285e10d76 ("arm64: dts: qcom: msm8998: add venus node")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 5038d0009c1a90851af1de91925facb4117d82fc..08a9e80ad6e1a17db1ced3a1ffc0c28bb35e84ad 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -116,6 +116,17 @@ mdata_mem: mpss-metadata {
 			size = <0x0 0x4000>;
 			no-map;
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x25800000>;
+		};
 	};
 
 	clocks {
@@ -3201,7 +3212,7 @@ venus: video-codec@cc00000 {
 				 <&mmss_smmu 0x42d>,
 				 <&mmss_smmu 0x411>,
 				 <&mmss_smmu 0x431>;
-			memory-region = <&venus_mem>;
+			memory-region = <&venus_mem>, <&venus_iova>;
 			status = "disabled";
 
 			video-decoder {

-- 
2.34.1

[PATCH 17/22] arm64: dts: qcom: sc7180: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 058bd0a68950 ("arm64: dts: sc7180: Move venus node to the correct position")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 70fbfb31d4a4dd0d0dd75feb37f686933ff38a14..4ea2dfe3110398ca3ec213301537a734b9cc1eb0 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -692,6 +692,17 @@ rmtfs_mem: memory@94600000 {
 			qcom,client-id = <1>;
 			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smem {
@@ -3155,7 +3166,7 @@ venus: video-codec@aa00000 {
 			clock-names = "core", "iface", "bus",
 				      "vcodec0_core", "vcodec0_bus";
 			iommus = <&apps_smmu 0x0c00 0x60>;
-			memory-region = <&venus_mem>;
+			memory-region = <&venus_mem>, <&venus_iova>;
 			interconnects = <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>,
 					<&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_VENUS_CFG 0>;
 			interconnect-names = "video-mem", "cpu-cfg";

-- 
2.34.1

[PATCH 18/22] arm64: dts: qcom: sdm630: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: f468ecf105de ("arm64: dts: qcom: sdm630: Add disabled Venus support")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sdm630.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index a41ba0da380bb97cefd8861837d06848f5d0f584..a80ae33f2c45c054cfce5f51b8cbc93c587304bf 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -518,6 +518,17 @@ mdata_mem: mpss-metadata {
 			size = <0x0 0x4000>;
 			no-map;
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x25800000>;
+		};
 	};
 
 	smem: smem {
@@ -2243,7 +2254,7 @@ venus: video-codec@cc00000 {
 				 <&mmss_smmu 0x42d>,
 				 <&mmss_smmu 0x411>,
 				 <&mmss_smmu 0x431>;
-			memory-region = <&venus_region>;
+			memory-region = <&venus_region>, <&venus_iova>;
 			power-domains = <&mmcc VENUS_GDSC>;
 			status = "disabled";
 

-- 
2.34.1

[PATCH 19/22] arm64: dts: qcom: sdm845: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: 36a80df44b6f ("arm64: dts: sdm845: Add video nodes")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index b1f6782a3ad9faf16e083d63cb8a6ea1507d4131..442834f394e6412386917b93f12f22069c4633f1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -898,6 +898,17 @@ fastrpc_mem: fastrpc {
 			size = <0x0 0x1000000>;
 			reusable;
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	adsp_pas: remoteproc-adsp {
@@ -4346,7 +4357,7 @@ venus: video-codec@aa00000 {
 				      "vcodec1_core", "vcodec1_bus";
 			iommus = <&apps_smmu 0x10a0 0x8>,
 				 <&apps_smmu 0x10b0 0x0>;
-			memory-region = <&venus_mem>;
+			memory-region = <&venus_mem>, <&venus_iova>;
 			interconnects = <&mmss_noc MASTER_VIDEO_P0 0 &mem_noc SLAVE_EBI1 0>,
 					<&gladiator_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_VENUS_CFG 0>;
 			interconnect-names = "video-mem", "cpu-cfg";

-- 
2.34.1

[PATCH 20/22] arm64: dts: qcom: sm6115: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: e0511284f0c1 ("arm64: dts: qcom: sm6115: add venus device")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm6115.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi
index 3520802d1fed57fa722371424cb11a33b277de1a..93f4eb8d18a7161fdee2ab67cdc0b4e8f327e9ee 100644
--- a/arch/arm64/boot/dts/qcom/sm6115.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi
@@ -532,6 +532,17 @@ rmtfs_mem: memory@89b01000 {
 			qcom,client-id = <1>;
 			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA QCOM_SCM_VMID_NAV>;
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smp2p-adsp {
@@ -1880,7 +1891,7 @@ venus: video-codec@5a00000 {
 				      "vcodec0_core",
 				      "vcodec0_bus";
 
-			memory-region = <&pil_video_mem>;
+			memory-region = <&pil_video_mem>, <&venus_iova>;
 			iommus = <&apps_smmu 0x860 0x0>,
 				 <&apps_smmu 0x880 0x0>;
 

-- 
2.34.1

[PATCH 21/22] arm64: dts: qcom: sm8250: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: fa245b3f06cd ("arm64: dts: qcom: sm8250: Add venus DT node")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 90f8b091634e9fbfb8d01632ec65e3e7f9e5bf2a..4183414c956aa9cb71dd5cfac3d24f34886592ea 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -872,6 +872,17 @@ adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
 			alignment = <0x0 0x400000>;
 			size = <0x0 0x800000>;
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	smem {
@@ -4353,7 +4364,7 @@ venus: video-codec@aa00000 {
 			interconnect-names = "cpu-cfg", "video-mem";
 
 			iommus = <&apps_smmu 0x2100 0x0400>;
-			memory-region = <&video_mem>;
+			memory-region = <&video_mem>, <&venus_iova>;
 
 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>,
 				 <&videocc VIDEO_CC_MVS0C_CLK_ARES>;

-- 
2.34.1

[PATCH 22/22] arm64: dts: qcom: talos: Reserve low IOVA range for Venus

[Vikash Garodia]

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. DMA into that range, from any other stream id
would triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with one or more browser tabs
driving multiple concurrent video decode streams.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
and reference it from the venus node so the IOMMU layer keeps DMA
allocations above that boundary.

Fixes: b83d3cc7a59c ("arm64: dts: qcom: sm6150: add venus node to devicetree")
Cc: stable@vger.kernel.org
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/talos.dtsi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index eedfdce3c479e704537fb8df7345452fe063d9c3..8645b04e266438857647600f4cf129dec9951c53 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -687,6 +687,17 @@ adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
 			alignment = <0x0 0x400000>;
 			size = <0x0 0x800000>;
 		};
+
+		/*
+		 * The Venus VPU reserves IOVA below 0x25800000 (600MB),
+		 * primarily for non-pixel buffers using different Stream IDs.
+		 * DMA into that range triggers unhandled SMMU faults and
+		 * spontaneous reboots, so reserve it to keep IOMMU
+		 * allocations above this boundary.
+		 */
+		venus_iova: venus-iova {
+			iommu-addresses = <&venus 0x0 0x0 0x0 0x25800000>;
+		};
 	};
 
 	soc: soc@0 {
@@ -4116,7 +4127,7 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 
 			iommus = <&apps_smmu 0xe60 0x20>;
 
-			memory-region = <&pil_video_mem>;
+			memory-region = <&pil_video_mem>, <&venus_iova>;
 
 			status = "disabled";
 

-- 
2.34.1

Re: [PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs

[Bryan O'Donoghue]

On 07/08/2026 09:24, Vikash Garodia wrote:
> Qualcomm venus and iris VPUs reserve IOVA addresses below 0x25800000
> (600MB) for non-pixel stream ID in secure mode. When the kernel
> allocates DMA mappings from this restricted range, the VPU generate
> unhandled SMMU page faults, leading to video failures and, in some
> cases, spontaneous system reboots.
> 
> The issue is readily reproducible on affected platforms by running
> multiple concurrent video decode workloads, such as opening several
> browser tabs containing video streams.
> 
> To prevent allocations in the restricted region, this series introduces
> support for an IOMMU IOVA reserve memory-region in the Venus and Iris
> bindings and updates all affected device trees to reserve the low IOVA
> range [0, 0x25800000]. The memory-region is referenced by the video codec
> node, allowing the IOMMU layer to keep DMA allocations above the reserved
> boundary.
> 
> The series consists of:
> 
>    * Binding updates for Venus and Iris schemas to permit an additional
>      memory-region phandle describing the IOVA reservation.
>    * DTS updates for all affected Venus platforms.
>    * DTS updates for all affected Iris platforms.
> 
> This ensures that DMA allocations do not overlap restricted IOVA
> mappings for non-pixel stream IDs and prevents the resulting SMMU
> faults.
LGTM

For the series.

Reviewed-by: Bryan O'Donoghue <bod@kernel.org>

---
bod

Re: [PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs

[Dmitry Baryshkov]

On Fri, Aug 07, 2026 at 01:54:44PM +0530, Vikash Garodia wrote:
> Qualcomm venus and iris VPUs reserve IOVA addresses below 0x25800000 
> (600MB) for non-pixel stream ID in secure mode. When the kernel 
> allocates DMA mappings from this restricted range, the VPU generate 
> unhandled SMMU page faults, leading to video failures and, in some 
> cases, spontaneous system reboots.
>  
> The issue is readily reproducible on affected platforms by running
> multiple concurrent video decode workloads, such as opening several
> browser tabs containing video streams.
> 
> To prevent allocations in the restricted region, this series introduces
> support for an IOMMU IOVA reserve memory-region in the Venus and Iris
> bindings and updates all affected device trees to reserve the low IOVA
> range [0, 0x25800000]. The memory-region is referenced by the video codec
> node, allowing the IOMMU layer to keep DMA allocations above the reserved
> boundary.
>  
> The series consists of:
>  
>   * Binding updates for Venus and Iris schemas to permit an additional
>     memory-region phandle describing the IOVA reservation.
>   * DTS updates for all affected Venus platforms.
>   * DTS updates for all affected Iris platforms.
>  
> This ensures that DMA allocations do not overlap restricted IOVA
> mappings for non-pixel stream IDs and prevents the resulting SMMU
> faults.

Some of these patches have been sent already. Why is it again at v1?

> 
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> Daniel J Blueman (2):
>       dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region
>       arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
> 
> Vikash Garodia (20):
>       dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region
>       dt-bindings: media: qcom,sc7180-venus: Allow IOVA reservation memory-region
>       arm64: dts: qcom: lemans: Reserve low IOVA range for Iris
>       arm64: dts: qcom: monaco: Reserve low IOVA range for Iris
>       arm64: dts: qcom: sc8280xp: Reserve low IOVA range for Iris
>       arm64: dts: qcom: sm8350: Reserve low IOVA range for Iris
>       arm64: dts: qcom: sm8550: Reserve low IOVA range for Iris
>       arm64: dts: qcom: sm8650: Reserve low IOVA range for Iris
>       arm64: dts: qcom: sm8750: Reserve low IOVA range for Iris
>       arm64: dts: qcom: agatti: Reserve low IOVA range for Venus
>       arm64: dts: qcom: kodiak: Reserve low IOVA range for Venus
>       arm64: dts: qcom: msm8916: Reserve low IOVA range for Venus
>       arm64: dts: qcom: msm8996: Reserve low IOVA range for Venus
>       arm64: dts: qcom: msm8998: Reserve low IOVA range for Venus
>       arm64: dts: qcom: sc7180: Reserve low IOVA range for Venus
>       arm64: dts: qcom: sdm630: Reserve low IOVA range for Venus
>       arm64: dts: qcom: sdm845: Reserve low IOVA range for Venus
>       arm64: dts: qcom: sm6115: Reserve low IOVA range for Venus
>       arm64: dts: qcom: sm8250: Reserve low IOVA range for Venus
>       arm64: dts: qcom: talos: Reserve low IOVA range for Venus
> 

-- 
With best wishes
Dmitry

Re: [PATCH 02/22] dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region

[Dmitry Baryshkov]

On Fri, Aug 07, 2026 at 01:54:46PM +0530, Vikash Garodia wrote:
> From: Daniel J Blueman <daniel@quora.org>
> 
> Non-pixel stream IDs should not allocate IOVA space from the 0 to 600MB
> restricted region, as this region is reserved exclusively for secure
> non-pixel.
> 
> In addition to the firmware-loaded codec carveout, Iris platforms need
> to declare an IOMMU IOVA reservation (a reserved-memory node with
> iommu-addresses) to keep DMA away from restricted IOVA range.
> 
> Permit a second memory-region phandle for this purpose, and describe
> the meaning of each entry so the ordering is unambiguous.
> 
> Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index 0400ca1bff05dcef6b742c3fbf77e38adca9f280..7dff7293fd5c834b0ea617ece87ffbf0d40e821a 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -84,7 +84,10 @@ properties:
>    dma-coherent: true
>  
>    memory-region:
> -    maxItems: 1
> +    minItems: 1
> +    items:
> +      - description: Firmware-loaded codec carveout
> +      - description: IOMMU IOVA reservation region

And how does it work if there is no firmware carveout?

-- 
With best wishes
Dmitry

Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

[Dmitry Baryshkov]

On Fri, Aug 07, 2026 at 01:54:48PM +0530, Vikash Garodia wrote:
> From: Daniel J Blueman <daniel@quora.org>
> 
> On X1-family hamoa platforms, the Iris VPU reserves IOVA addresses
> below 0x25800000 (600MB), primarily for secure non-pixel buffers. DMA
> into that range, from any other stream id would triggers unhandled SMMU
> page faults that cause spontaneous device reboots. This is readily
> reproduced with one or more browser tabs driving multiple concurrent
> video decode streams.
> 
> Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
> and reference it from the Iris node so the IOMMU layer keeps DMA
> allocations above that boundary.
> 
> Link: https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574
> Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/hamoa.dtsi | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index 8a96ea1bdb9c4c409b2af997680d8c13fed0643e..87f424765d513c97b06303bceb75ca9f176d2ace 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -666,6 +666,17 @@ smem_mem: smem@ffe00000 {
>  			hwlocks = <&tcsr_mutex 3>;
>  			no-map;
>  		};
> +
> +		/*
> +		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
> +		 * primarily for non-pixel buffers using different Stream IDs.
> +		 * DMA into that range triggers unhandled SMMU faults and
> +		 * spontaneous reboots, so reserve it to keep IOMMU
> +		 * allocations above this boundary.
> +		 */
> +		iris_iova: iris-iova {
> +			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
> +		};
>  	};
>  
>  	qup_opp_table_100mhz: opp-table-qup100mhz {
> @@ -5439,7 +5450,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>  			interconnect-names = "cpu-cfg",
>  					     "video-mem";
>  
> -			memory-region = <&video_mem>;
> +			memory-region = <&video_mem>, <&iris_iova>;

I don't like the idea of this series, because it _again_ doesn't tell us
the truth about the hardware. This typicall ends up with bigger problems
later on, when it starts to affect other bits and pieces.

I don't want to NAK it, but I'd strongly ask to reconsider it.

>  
>  			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>  			reset-names = "bus";
> 
> -- 
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs

[Vikash Garodia]

On 8/7/2026 2:29 PM, Dmitry Baryshkov wrote:
> On Fri, Aug 07, 2026 at 01:54:44PM +0530, Vikash Garodia wrote:
>> Qualcomm venus and iris VPUs reserve IOVA addresses below 0x25800000
>> (600MB) for non-pixel stream ID in secure mode. When the kernel
>> allocates DMA mappings from this restricted range, the VPU generate
>> unhandled SMMU page faults, leading to video failures and, in some
>> cases, spontaneous system reboots.
>>   
>> The issue is readily reproducible on affected platforms by running
>> multiple concurrent video decode workloads, such as opening several
>> browser tabs containing video streams.
>>
>> To prevent allocations in the restricted region, this series introduces
>> support for an IOMMU IOVA reserve memory-region in the Venus and Iris
>> bindings and updates all affected device trees to reserve the low IOVA
>> range [0, 0x25800000]. The memory-region is referenced by the video codec
>> node, allowing the IOMMU layer to keep DMA allocations above the reserved
>> boundary.
>>   
>> The series consists of:
>>   
>>    * Binding updates for Venus and Iris schemas to permit an additional
>>      memory-region phandle describing the IOVA reservation.
>>    * DTS updates for all affected Venus platforms.
>>    * DTS updates for all affected Iris platforms.
>>   
>> This ensures that DMA allocations do not overlap restricted IOVA
>> mappings for non-pixel stream IDs and prevents the resulting SMMU
>> faults.
> Some of these patches have been sent already. Why is it again at v1?

By some, i assume you are referring to the 2 patches from Daniel. Kept 
it as part of this series to maintain the continuity with patches across 
other socs, other option would be to bring them as dependency and drop 
them from here.

> 
>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> ---
>> Daniel J Blueman (2):
>>        dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region
>>        arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
>>
>> Vikash Garodia (20):
>>        dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region

Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

[Vikash Garodia]

On 8/7/2026 2:33 PM, Dmitry Baryshkov wrote:
> On Fri, Aug 07, 2026 at 01:54:48PM +0530, Vikash Garodia wrote:
>> From: Daniel J Blueman <daniel@quora.org>
>>
>> On X1-family hamoa platforms, the Iris VPU reserves IOVA addresses
>> below 0x25800000 (600MB), primarily for secure non-pixel buffers. DMA
>> into that range, from any other stream id would triggers unhandled SMMU
>> page faults that cause spontaneous device reboots. This is readily
>> reproduced with one or more browser tabs driving multiple concurrent
>> video decode streams.
>>
>> Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
>> and reference it from the Iris node so the IOMMU layer keeps DMA
>> allocations above that boundary.
>>
>> Link: https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574
>> Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Daniel J Blueman <daniel@quora.org>
>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>> ---
>>   arch/arm64/boot/dts/qcom/hamoa.dtsi | 13 ++++++++++++-
>>   1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> index 8a96ea1bdb9c4c409b2af997680d8c13fed0643e..87f424765d513c97b06303bceb75ca9f176d2ace 100644
>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>> @@ -666,6 +666,17 @@ smem_mem: smem@ffe00000 {
>>   			hwlocks = <&tcsr_mutex 3>;
>>   			no-map;
>>   		};
>> +
>> +		/*
>> +		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
>> +		 * primarily for non-pixel buffers using different Stream IDs.
>> +		 * DMA into that range triggers unhandled SMMU faults and
>> +		 * spontaneous reboots, so reserve it to keep IOMMU
>> +		 * allocations above this boundary.
>> +		 */
>> +		iris_iova: iris-iova {
>> +			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
>> +		};
>>   	};
>>   
>>   	qup_opp_table_100mhz: opp-table-qup100mhz {
>> @@ -5439,7 +5450,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>>   			interconnect-names = "cpu-cfg",
>>   					     "video-mem";
>>   
>> -			memory-region = <&video_mem>;
>> +			memory-region = <&video_mem>, <&iris_iova>;
> 
> I don't like the idea of this series, because it _again_ doesn't tell us
> the truth about the hardware. This typicall ends up with bigger problems

honestly...thats all the info i have about the vpu hardware that it 
restricts non pixel to DMA from the 0-600MB range. The same i have been 
trying for a year now

https://lore.kernel.org/all/20250627-video_cb-v3-1-51e18c0ffbce@quicinc.com/

> later on, when it starts to affect other bits and pieces.
> 
> I don't want to NAK it, but I'd strongly ask to reconsider it.
> 
>>   
>>   			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>>   			reset-names = "bus";
>>
>> -- 
>> 2.34.1
>>
> 

Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

[Dmitry Baryshkov]

On Fri, Aug 07, 2026 at 02:56:27PM +0530, Vikash Garodia wrote:
> 
> On 8/7/2026 2:33 PM, Dmitry Baryshkov wrote:
> > On Fri, Aug 07, 2026 at 01:54:48PM +0530, Vikash Garodia wrote:
> > > From: Daniel J Blueman <daniel@quora.org>
> > > 
> > > On X1-family hamoa platforms, the Iris VPU reserves IOVA addresses
> > > below 0x25800000 (600MB), primarily for secure non-pixel buffers. DMA
> > > into that range, from any other stream id would triggers unhandled SMMU
> > > page faults that cause spontaneous device reboots. This is readily
> > > reproduced with one or more browser tabs driving multiple concurrent
> > > video decode streams.
> > > 
> > > Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
> > > and reference it from the Iris node so the IOMMU layer keeps DMA
> > > allocations above that boundary.
> > > 
> > > Link: https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574
> > > Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Daniel J Blueman <daniel@quora.org>
> > > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> > > ---
> > >   arch/arm64/boot/dts/qcom/hamoa.dtsi | 13 ++++++++++++-
> > >   1 file changed, 12 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > > index 8a96ea1bdb9c4c409b2af997680d8c13fed0643e..87f424765d513c97b06303bceb75ca9f176d2ace 100644
> > > --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > > @@ -666,6 +666,17 @@ smem_mem: smem@ffe00000 {
> > >   			hwlocks = <&tcsr_mutex 3>;
> > >   			no-map;
> > >   		};
> > > +
> > > +		/*
> > > +		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
> > > +		 * primarily for non-pixel buffers using different Stream IDs.
> > > +		 * DMA into that range triggers unhandled SMMU faults and
> > > +		 * spontaneous reboots, so reserve it to keep IOMMU
> > > +		 * allocations above this boundary.
> > > +		 */
> > > +		iris_iova: iris-iova {
> > > +			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
> > > +		};
> > >   	};
> > >   	qup_opp_table_100mhz: opp-table-qup100mhz {
> > > @@ -5439,7 +5450,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> > >   			interconnect-names = "cpu-cfg",
> > >   					     "video-mem";
> > > -			memory-region = <&video_mem>;
> > > +			memory-region = <&video_mem>, <&iris_iova>;
> > 
> > I don't like the idea of this series, because it _again_ doesn't tell us
> > the truth about the hardware. This typicall ends up with bigger problems
> 
> honestly...thats all the info i have about the vpu hardware that it
> restricts non pixel to DMA from the 0-600MB range. The same i have been
> trying for a year now

You are not honest here. You also know that there are secure streams,
which have to use their own IOMMU SIDs. And some of them, as far as I
remember, also have memory range restrictions.

So, if we land these patches, how do extend it later to account for all
of that?

> 
> https://lore.kernel.org/all/20250627-video_cb-v3-1-51e18c0ffbce@quicinc.com/
> 
> > later on, when it starts to affect other bits and pieces.
> > 
> > I don't want to NAK it, but I'd strongly ask to reconsider it.
> > 
> > >   			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
> > >   			reset-names = "bus";
> > > 
> > > -- 
> > > 2.34.1
> > > 
> > 
> 

-- 
With best wishes
Dmitry

Re: [PATCH 00/22] media: iris: Restrict lower IOVA range for Venus and Iris VPUs

[Dmitry Baryshkov]

On Fri, Aug 07, 2026 at 02:35:29PM +0530, Vikash Garodia wrote:
> 
> On 8/7/2026 2:29 PM, Dmitry Baryshkov wrote:
> > On Fri, Aug 07, 2026 at 01:54:44PM +0530, Vikash Garodia wrote:
> > > Qualcomm venus and iris VPUs reserve IOVA addresses below 0x25800000
> > > (600MB) for non-pixel stream ID in secure mode. When the kernel
> > > allocates DMA mappings from this restricted range, the VPU generate
> > > unhandled SMMU page faults, leading to video failures and, in some
> > > cases, spontaneous system reboots.
> > > The issue is readily reproducible on affected platforms by running
> > > multiple concurrent video decode workloads, such as opening several
> > > browser tabs containing video streams.
> > > 
> > > To prevent allocations in the restricted region, this series introduces
> > > support for an IOMMU IOVA reserve memory-region in the Venus and Iris
> > > bindings and updates all affected device trees to reserve the low IOVA
> > > range [0, 0x25800000]. The memory-region is referenced by the video codec
> > > node, allowing the IOMMU layer to keep DMA allocations above the reserved
> > > boundary.
> > > The series consists of:
> > >    * Binding updates for Venus and Iris schemas to permit an additional
> > >      memory-region phandle describing the IOVA reservation.
> > >    * DTS updates for all affected Venus platforms.
> > >    * DTS updates for all affected Iris platforms.
> > > This ensures that DMA allocations do not overlap restricted IOVA
> > > mappings for non-pixel stream IDs and prevents the resulting SMMU
> > > faults.
> > Some of these patches have been sent already. Why is it again at v1?
> 
> By some, i assume you are referring to the 2 patches from Daniel. Kept it as
> part of this series to maintain the continuity with patches across other
> socs, other option would be to bring them as dependency and drop them from
> here.

So, your series should have been v2 at least. V1 has already sailed.

-- 
With best wishes
Dmitry

Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

[Vikash Garodia]

On 8/7/2026 3:30 PM, Dmitry Baryshkov wrote:
> On Fri, Aug 07, 2026 at 02:56:27PM +0530, Vikash Garodia wrote:
>>
>> On 8/7/2026 2:33 PM, Dmitry Baryshkov wrote:
>>> On Fri, Aug 07, 2026 at 01:54:48PM +0530, Vikash Garodia wrote:
>>>> From: Daniel J Blueman <daniel@quora.org>
>>>>
>>>> On X1-family hamoa platforms, the Iris VPU reserves IOVA addresses
>>>> below 0x25800000 (600MB), primarily for secure non-pixel buffers. DMA
>>>> into that range, from any other stream id would triggers unhandled SMMU
>>>> page faults that cause spontaneous device reboots. This is readily
>>>> reproduced with one or more browser tabs driving multiple concurrent
>>>> video decode streams.
>>>>
>>>> Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
>>>> and reference it from the Iris node so the IOMMU layer keeps DMA
>>>> allocations above that boundary.
>>>>
>>>> Link: https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574
>>>> Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
>>>> Cc: stable@vger.kernel.org
>>>> Signed-off-by: Daniel J Blueman <daniel@quora.org>
>>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>>> ---
>>>>    arch/arm64/boot/dts/qcom/hamoa.dtsi | 13 ++++++++++++-
>>>>    1 file changed, 12 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>>> index 8a96ea1bdb9c4c409b2af997680d8c13fed0643e..87f424765d513c97b06303bceb75ca9f176d2ace 100644
>>>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>>> @@ -666,6 +666,17 @@ smem_mem: smem@ffe00000 {
>>>>    			hwlocks = <&tcsr_mutex 3>;
>>>>    			no-map;
>>>>    		};
>>>> +
>>>> +		/*
>>>> +		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
>>>> +		 * primarily for non-pixel buffers using different Stream IDs.
>>>> +		 * DMA into that range triggers unhandled SMMU faults and
>>>> +		 * spontaneous reboots, so reserve it to keep IOMMU
>>>> +		 * allocations above this boundary.
>>>> +		 */
>>>> +		iris_iova: iris-iova {
>>>> +			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
>>>> +		};
>>>>    	};
>>>>    	qup_opp_table_100mhz: opp-table-qup100mhz {
>>>> @@ -5439,7 +5450,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>>>>    			interconnect-names = "cpu-cfg",
>>>>    					     "video-mem";
>>>> -			memory-region = <&video_mem>;
>>>> +			memory-region = <&video_mem>, <&iris_iova>;
>>>
>>> I don't like the idea of this series, because it _again_ doesn't tell us
>>> the truth about the hardware. This typicall ends up with bigger problems
>>
>> honestly...thats all the info i have about the vpu hardware that it
>> restricts non pixel to DMA from the 0-600MB range. The same i have been
>> trying for a year now
> 
> You are not honest here. You also know that there are secure streams,
> which have to use their own IOMMU SIDs. And some of them, as far as I
> remember, also have memory range restrictions.

please read the commit description again, the answer is there.

> 
> So, if we land these patches, how do extend it later to account for all
> of that?
> 

forward looking design would be subnode, which we can land ontop of this 
series.

>>
>> https://lore.kernel.org/all/20250627-video_cb-v3-1-51e18c0ffbce@quicinc.com/
>>
>>> later on, when it starts to affect other bits and pieces.
>>>
>>> I don't want to NAK it, but I'd strongly ask to reconsider it.
>>>
>>>>    			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
>>>>    			reset-names = "bus";
>>>>
>>>> -- 
>>>> 2.34.1
>>>>
>>>
>>
> 

Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

[Bryan O'Donoghue]

On 07/08/2026 11:22, Vikash Garodia wrote:
>>>> I don't like the idea of this series, because it_again_ doesn't tell us
>>>> the truth about the hardware. This typicall ends up with bigger problems
>>> honestly...thats all the info i have about the vpu hardware that it
>>> restricts non pixel to DMA from the 0-600MB range. The same i have been
>>> trying for a year now
>> You are not honest here. You also know that there are secure streams,
>> which have to use their own IOMMU SIDs. And some of them, as far as I
>> remember, also have memory range restrictions.
> please read the commit description again, the answer is there.

So I don't necessarily get all of the detail out of the commit log myself.

Could you give some detail to address Dmitry's point.

The question as I read it is - are all of the other potential SIDs 
covered by this change ?

>> So, if we land these patches, how do extend it later to account for all
>> of that?
>>
> forward looking design would be subnode, which we can land ontop of this
> series.

Yes it should be possible to branch to make subnodes work on-top of this 
- accepting that once this lands it becomes ABI and support for this 
method must be sustained, even after sub-nodes land.

---
bod

Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

[Rob Herring]

On Fri, Aug 07, 2026 at 12:03:50PM +0300, Dmitry Baryshkov wrote:
> On Fri, Aug 07, 2026 at 01:54:48PM +0530, Vikash Garodia wrote:
> > From: Daniel J Blueman <daniel@quora.org>
> > 
> > On X1-family hamoa platforms, the Iris VPU reserves IOVA addresses
> > below 0x25800000 (600MB), primarily for secure non-pixel buffers. DMA
> > into that range, from any other stream id would triggers unhandled SMMU
> > page faults that cause spontaneous device reboots. This is readily
> > reproduced with one or more browser tabs driving multiple concurrent
> > video decode streams.
> > 
> > Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
> > and reference it from the Iris node so the IOMMU layer keeps DMA
> > allocations above that boundary.
> > 
> > Link: https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574
> > Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Daniel J Blueman <daniel@quora.org>
> > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> > ---
> >  arch/arm64/boot/dts/qcom/hamoa.dtsi | 13 ++++++++++++-
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > index 8a96ea1bdb9c4c409b2af997680d8c13fed0643e..87f424765d513c97b06303bceb75ca9f176d2ace 100644
> > --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> > @@ -666,6 +666,17 @@ smem_mem: smem@ffe00000 {
> >  			hwlocks = <&tcsr_mutex 3>;
> >  			no-map;
> >  		};
> > +
> > +		/*
> > +		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
> > +		 * primarily for non-pixel buffers using different Stream IDs.
> > +		 * DMA into that range triggers unhandled SMMU faults and
> > +		 * spontaneous reboots, so reserve it to keep IOMMU
> > +		 * allocations above this boundary.
> > +		 */
> > +		iris_iova: iris-iova {
> > +			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
> > +		};
> >  	};
> >  
> >  	qup_opp_table_100mhz: opp-table-qup100mhz {
> > @@ -5439,7 +5450,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> >  			interconnect-names = "cpu-cfg",
> >  					     "video-mem";
> >  
> > -			memory-region = <&video_mem>;
> > +			memory-region = <&video_mem>, <&iris_iova>;
> 
> I don't like the idea of this series, because it _again_ doesn't tell us
> the truth about the hardware. This typicall ends up with bigger problems
> later on, when it starts to affect other bits and pieces.
> 
> I don't want to NAK it, but I'd strongly ask to reconsider it.

I think this is an abuse of /reserved-memory. reserved-memory is 
reserved *physical* memory. Reserved IOVA is a property on top of that. 
I'm surprised this passes validation. If it does, I may go fix that.

Rob

Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

[Vishnu Reddy]

On 8/7/2026 9:54 PM, Rob Herring wrote:
> On Fri, Aug 07, 2026 at 12:03:50PM +0300, Dmitry Baryshkov wrote:
>> On Fri, Aug 07, 2026 at 01:54:48PM +0530, Vikash Garodia wrote:
>>> From: Daniel J Blueman <daniel@quora.org>
>>>
>>> On X1-family hamoa platforms, the Iris VPU reserves IOVA addresses
>>> below 0x25800000 (600MB), primarily for secure non-pixel buffers. DMA
>>> into that range, from any other stream id would triggers unhandled SMMU
>>> page faults that cause spontaneous device reboots. This is readily
>>> reproduced with one or more browser tabs driving multiple concurrent
>>> video decode streams.
>>>
>>> Add a reserved-memory IOVA reservation node covering [0, 0x25800000]
>>> and reference it from the Iris node so the IOMMU layer keeps DMA
>>> allocations above that boundary.
>>>
>>> Link: https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574
>>> Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Daniel J Blueman <daniel@quora.org>
>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>> ---
>>>  arch/arm64/boot/dts/qcom/hamoa.dtsi | 13 ++++++++++++-
>>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>> index 8a96ea1bdb9c4c409b2af997680d8c13fed0643e..87f424765d513c97b06303bceb75ca9f176d2ace 100644
>>> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
>>> @@ -666,6 +666,17 @@ smem_mem: smem@ffe00000 {
>>>  			hwlocks = <&tcsr_mutex 3>;
>>>  			no-map;
>>>  		};
>>> +
>>> +		/*
>>> +		 * The Iris VPU reserves IOVA below 0x25800000 (600MB),
>>> +		 * primarily for non-pixel buffers using different Stream IDs.
>>> +		 * DMA into that range triggers unhandled SMMU faults and
>>> +		 * spontaneous reboots, so reserve it to keep IOMMU
>>> +		 * allocations above this boundary.
>>> +		 */
>>> +		iris_iova: iris-iova {
>>> +			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
>>> +		};
>>>  	};
>>>  
>>>  	qup_opp_table_100mhz: opp-table-qup100mhz {
>>> @@ -5439,7 +5450,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
>>>  			interconnect-names = "cpu-cfg",
>>>  					     "video-mem";
>>>  
>>> -			memory-region = <&video_mem>;
>>> +			memory-region = <&video_mem>, <&iris_iova>;
>> I don't like the idea of this series, because it _again_ doesn't tell us
>> the truth about the hardware. This typicall ends up with bigger problems
>> later on, when it starts to affect other bits and pieces.
>>
>> I don't want to NAK it, but I'd strongly ask to reconsider it.
> I think this is an abuse of /reserved-memory. reserved-memory is 
> reserved *physical* memory. Reserved IOVA is a property on top of that. 
> I'm surprised this passes validation. If it does, I may go fix that.

As per the reserved-memory.yaml schema document, the iommu-addresses
property for IOVA reservation into /reserved-memory is allowed — it's
documented for IOVA carveout reservations:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml#L56

> Rob
>