[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch updates `qcom,venus-common.yaml` to permit a second `memory-region` phandle for an IOMMU IOVA reservation, but fails to remove a stale `maxItems: 1` constraint from `qcom,sc7180-venus.yaml`. This prevents SC7180 devices from successfully validating if they supply the newly permitted second region.
--

--- Patch [1]: [PATCH 01/22] dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region ---
commit 44e20424e211e02ef9914abe4592c185ad0d75ac
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region

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.

> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
> index 59a3fde846d21..0be2f9119e782 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

[Severity: Medium]
Since this patch expands the common schema to allow two memory-region items,
should the local constraints in related variant schemas also be updated?

For example, the local constraint in qcom,sc7180-venus.yaml restricts the
items to 1:

Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml:properties.memory-region {
    ...
  memory-region:
    maxItems: 1
    ...
}

Because dt-schema evaluates a logical AND between local constraints and
the included $ref schemas, won't SC7180 device trees fail dt_binding_check
validation if they declare the newly permitted IOVA reservation region?

>  
>    power-domains:
>      minItems: 1

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=1

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

[Vikash Garodia]

On 8/7/2026 2:19 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The patch updates `qcom,venus-common.yaml` to permit a second `memory-region` phandle for an IOMMU IOVA reservation, but fails to remove a stale `maxItems: 1` constraint from `qcom,sc7180-venus.yaml`. This prevents SC7180 devices from successfully validating if they supply the newly permitted second region.

patch #3 in this series incorporates this comment.

> --
> 
> --- Patch [1]: [PATCH 01/22] dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region ---
> commit 44e20424e211e02ef9914abe4592c185ad0d75ac
> Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> 
> dt-bindings: media: qcom,venus-common: Allow IOVA reservation memory-region
> 
> 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.
> 
>> diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml
>> index 59a3fde846d21..0be2f9119e782 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
> 
> [Severity: Medium]
> Since this patch expands the common schema to allow two memory-region items,
> should the local constraints in related variant schemas also be updated?
> 
> For example, the local constraint in qcom,sc7180-venus.yaml restricts the
> items to 1:
> 
> Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml:properties.memory-region {
>      ...
>    memory-region:
>      maxItems: 1
>      ...
> }
> 
> Because dt-schema evaluates a logical AND between local constraints and
> the included $ref schemas, won't SC7180 device trees fail dt_binding_check
> validation if they declare the newly permitted IOVA reservation region?
> 
>>   
>>     power-domains:
>>       minItems: 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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] NULL pointer dereference when `of_translate_dma_region()` fails.
- [High] Parsing desynchronization when `iommu-addresses` contains entries for different devices.
--

--- Patch [2]: [PATCH 02/22] dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region ---
commit 75d07dc0e88c8eab8911e5e4c741c2ddba6cf12f
Author: Daniel J Blueman <daniel@quora.org>

dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region

Non-pixel stream IDs should not allocate IOVA space from the restricted region,
as this region is reserved exclusively for secure non-pixel. Iris platforms
must declare an IOMMU IOVA reservation to keep DMA away from this range. This
patch permits a second memory-region phandle for this purpose and describes
each entry.

> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index 0400ca1bff05d..7dff7293fd5c8 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

[Severity: High]
This isn't a bug introduced by this patch, but introducing memory-region nodes
utilizing iommu-addresses exposes a pre-existing NULL pointer dereference in
the boot/probe path.

When the iommu-addresses property is parsed in of_iommu_get_resv_regions(), if
of_translate_dma_region() fails (e.g. due to a missing parent bus or malformed
address), it returns NULL, which is directly assigned to the maps pointer:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
		if (np == dev->of_node) {
            ...
			maps = of_translate_dma_region(np, maps, &iova, &length);
    ...
}

Will this cause a kernel panic on the next iteration?

The check maps < end would evaluate to true (since end is a valid, non-zero
pointer), and the code then executes be32_to_cpup(maps++), which dereferences
the NULL pointer. Additionally, the length variable remains uninitialized on
this failure path:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
	while (maps < end) {
		struct device_node *np;
		u32 phandle;

		phandle = be32_to_cpup(maps++);
    ...
}

[Severity: High]
This is a pre-existing issue, but utilizing iommu-addresses exposes a parsing
desynchronization when the iommu-addresses property contains entries for
different devices.

If the parser reads an entry where the phandle does not match dev->of_node, it
skips processing but fails to advance the maps pointer past the address and
size cells:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
	while (maps < end) {
        ...
		phandle = be32_to_cpup(maps++);
		np = of_find_node_by_phandle(phandle);

		if (np == dev->of_node) {
            ...
			maps = of_translate_dma_region(np, maps, &iova, &length);
            ...
		}
	}
    ...
}

Does this completely desynchronize the parser?

On the next iteration, it seems the parser would read the first address cell
of the skipped entry as the next phandle, making it impossible to correctly
parse a shared memory-region node containing multiple devices.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=2

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

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing bounds check, incorrect pointer advancement, and potential NULL pointer dereference when parsing the `iommu-addresses` property.
--

--- Patch [4]: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris ---
commit 0d7d545a5dddd31b4e0cc75f7a486bdd8ebe240d
Author: Daniel J Blueman <daniel@quora.org>

arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

This commit adds a reserved iova region below 0x25800000 for the Iris vpu on
hamoa platforms to prevent smmu faults. It references this reserved memory
using the iommu-addresses property to keep dma allocations above the boundary.

Link: https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574

> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index 8a96ea1bdb9c4..87f424765d513 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>;

[Severity: High]
This isn't a bug introduced by this patch, but adding this iommu-addresses
property could trigger a pre-existing issue in the device tree parsing logic.

Looking at of_iommu_get_resv_regions() in drivers/iommu/of_iommu.c, when
parsing the iommu-addresses property, if a parsed phandle does not match
dev->of_node, the loop fails to skip the parent's na + ns cells:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
	while (maps < end) {
		struct device_node *np;
		u32 phandle;

		phandle = be32_to_cpup(maps++);
		np = of_find_node_by_phandle(phandle);

		if (np == dev->of_node) {
			// ...
			maps = of_translate_dma_region(np, maps, &iova, &length);
    ...
}

Because maps is only incremented by 1 cell (the phandle) instead of
1 + na + ns, the parser becomes misaligned. Subsequent iterations will
interpret address and size cells as phandles.

Additionally, if of_translate_dma_region() fails, it returns null. The loop
then assigns null to maps. Since end is a valid kernel pointer, the maps < end
check passes on the next iteration, and be32_to_cpup(maps++) dereferences the
null pointer.

Furthermore, in of_translate_dma_region(), there is no bounds checking against
the property's allocation size:

drivers/of/address.c:of_translate_dma_region() {
    ...
	address = of_translate_dma_address(dev, prop);
	if (address == OF_BAD_ADDR)
		return NULL;

	size = of_read_number(prop + na, ns);
    ...
}

If the parser is misaligned and a false match occurs near the end of the
buffer, this can read out-of-bounds heap memory.

Does this new device tree property risk exposing these parsing issues if
multiple entries or malformed data are present in the device tree?

> +		};
>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=4

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 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 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
>

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] of_iommu_get_resv_regions() fails to advance the 'maps' pointer when a parsed phandle does not match dev->of_node, leading to corrupted DT property parsing and out-of-bounds reads.
- [High] of_iommu_get_resv_regions() will dereference a NULL pointer and use uninitialized stack variables if of_translate_dma_region() fails.
- [Medium] Device node reference count leak in of_iommu_get_resv_regions().
--

--- Patch [5]: [PATCH 05/22] arm64: dts: qcom: lemans: Reserve low IOVA range for Iris ---
commit 4e0d92ff7cab972552bdfb654d8534c1ad241835
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: lemans: Reserve low IOVA range for Iris

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.

Fixes: 7bc95052c64f ("arm64: dts: qcom: sa8775p: add support for video node")
Cc: stable@vger.kernel.org

> diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
> index 695eae1b72569..da0326fe24485 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>;

[Severity: High]
This isn't a bug introduced by this patch, but adding this property might
trigger a pre-existing issue in
drivers/iommu/of_iommu.c:of_iommu_get_resv_regions().

If the iommu-addresses property contains multiple entries and the first
entry's phandle does not match dev->of_node, the code skips the if block
but fails to advance the maps pointer:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
	...
	if (np == dev->of_node) {
		// ... parses and advances maps ...
	}
	// MISSING ELSE BRANCH to advance maps pointer
	...
}

Will this cause the next iteration to incorrectly interpret the first address
cell of the unmatched entry as a phandle, reducing the parsing to a corrupted
word-by-word scan?

[Severity: Medium]
This is a pre-existing issue, but does of_iommu_get_resv_regions() leak the
device node reference count when parsing these iommu-addresses?

Every iteration of the loop fetches the node, but there is no corresponding
of_node_put(np) to release it:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
	...
	np = of_find_node_by_phandle(phandle);
	...
}

[Severity: High]
This is also a pre-existing issue, but what happens if
of_translate_dma_region() fails when parsing this property?

The maps pointer is reassigned to the return value without checking for NULL,
and the function relies on the uninitialized iova and length variables on
failure:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
	...
	maps = of_translate_dma_region(np, maps, &iova, &length);
	...
}

If of_translate_dma_region() returns NULL, the maps pointer is assigned NULL,
and the loop condition maps < end evaluates to true. Will the next iteration
then dereference the NULL maps pointer?

> +		};
>  	};

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=5

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Pre-existing flaws in `of_iommu_get_resv_regions` cause a kernel panic on translation failure, break parsing for multiple device entries, and leak device node references.
--

--- Patch [6]: [PATCH 06/22] arm64: dts: qcom: monaco: Reserve low IOVA range for Iris ---
commit 80dd45ef37e8a085b1612e1aef1e011d1e74726c
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: monaco: Reserve low IOVA range for Iris

Iris VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. Add a reserved-memory IOVA reservation node
covering [0, 0x25800000] and reference it from the Iris node.

> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index cfe39f923224f..048b4490fcafd 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>;

[Severity: High]
This is a pre-existing issue, but does using the iommu-addresses property
expose flaws in the underlying parser in of_iommu_get_resv_regions()?

Looking at drivers/iommu/of_iommu.c:of_iommu_get_resv_regions():

		while (maps < end) {
			struct device_node *np;
			u32 phandle;

			phandle = be32_to_cpup(maps++);
			np = of_find_node_by_phandle(phandle);

			if (np == dev->of_node) {
				...
				maps = of_translate_dma_region(np, maps, &iova, &length);

If of_translate_dma_region() fails, it returns NULL. The maps pointer becomes
NULL, and the while loop condition (maps < end) continues evaluating to true.
The next iteration calls be32_to_cpup(maps++), which dereferences NULL and
panics the kernel.

Additionally, if the parsed phandle does not match dev->of_node, maps is not
advanced past the skipped device's address and size cells. This causes the next
iteration to incorrectly read part of the DMA address as a phandle, which breaks
parsing for any property with multiple entries.

Finally, np is acquired via of_find_node_by_phandle() which increments the
refcount, but of_node_put() is never called to release it. Does this leak the
device node reference?

While this patch adds only a single-entry array and might bypass the multi-entry
parsing failure, the parser itself appears vulnerable to panicking on malformed
device trees.

> +		};
>  	};
>  
>  	smp2p-adsp {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=6

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] If `of_translate_dma_region()` fails during IOVA reservation parsing, it returns NULL, which causes a subsequent NULL pointer dereference on the next loop iteration.
- [Medium] The device node reference obtained via `of_find_node_by_phandle()` is never released, leading to a memory leak.
--

--- Patch [7]: [PATCH 07/22] arm64: dts: qcom: sc8280xp: Reserve low IOVA range for Iris ---
commit 5bb5ca70fa7d2aa5a3d66cdd7f006042161ce0dc
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sc8280xp: Reserve low IOVA range for Iris

This patch reserves an IOVA range for the Iris VPU to prevent unhandled
SMMU page faults when DMA accesses that range from other stream IDs. It
achieves this by adding a reserved-memory IOVA reservation node and
referencing it from the Iris node.

> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index fbcfd3883bbb4..1c624683d0033 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>;

[Severity: Medium]
This is a pre-existing issue, but does of_iommu_get_resv_regions() leak the
device node reference when processing the iommu-addresses property?

When parsing these nodes, the reference is acquired via
of_find_node_by_phandle():

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
		while (maps < end) {
			struct device_node *np;
			u32 phandle;

			phandle = be32_to_cpup(maps++);
			np = of_find_node_by_phandle(phandle);
    ...
}

But it looks like of_node_put(np) is never called within the loop or the
function, which would result in a leak on every element in the property.

[Severity: High]
This is a pre-existing issue, but is there a risk of a NULL pointer
dereference here if of_translate_dma_region() fails?

If the translation fails (for example, due to an invalid DMA parent),
of_translate_dma_region() returns NULL:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
				maps = of_translate_dma_region(np, maps, &iova, &length);
				if (length == 0) {
					dev_warn(dev, "Cannot reserve IOVA region of 0 size\n");
					continue;
				}
    ...
}

Since maps is updated to NULL, the loop condition (maps < end) still
evaluates to true. On the next iteration, be32_to_cpup(maps++) would
unconditionally dereference the NULL pointer:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
		while (maps < end) {
			struct device_node *np;
			u32 phandle;

			phandle = be32_to_cpup(maps++);
    ...
}

> +		};
>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=7

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Uninitialized variable usage and NULL pointer dereference in of_iommu_get_resv_regions() when of_translate_dma_region() fails.
--

--- Patch [8]: [PATCH 08/22] arm64: dts: qcom: sm8350: Reserve low IOVA range for Iris ---
commit ff9e2ea90c6d8293aa79fd7350941f4a90c4b7df
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sm8350: Reserve low IOVA range for Iris

The Iris VPU needs IOVA addresses below 0x25800000 reserved to prevent
unhandled SMMU page faults and reboots caused by DMA from other stream
IDs. This patch adds a reserved-memory IOVA reservation node and references
it from the Iris node.

Fixes: a2b0c5eba743 ("arm64: dts: qcom: sm8350: add Iris device")
Cc: stable@vger.kernel.org

> diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
> index 32b47f5ec1f67..b376dda0ed520 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>;

[Severity: High]
This isn't a bug introduced by this patch, but adding this iommu-addresses
property highlights a pre-existing issue in the parsing code. Does
of_iommu_get_resv_regions() safely handle translation failures?

Looking at drivers/iommu/of_iommu.c:of_iommu_get_resv_regions(), when
of_translate_dma_region() fails, it returns NULL:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    maps = of_translate_dma_region(np, maps, &iova, &length);
    if (length == 0) {
    ...
}

The return value is assigned directly to maps without checking for NULL,
leaving the iova and length stack variables uninitialized.

If the loop continues to the next iteration, it attempts to dereference
maps:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    phandle = be32_to_cpup(maps++);
    ...
}

This causes a NULL pointer dereference and a kernel panic.

Could the parsing code in of_iommu.c be hardened to gracefully handle
invalid or untranslatable data without panicking?

> +		};
>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=8

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] Kernel panic via NULL pointer dereference in `of_iommu_get_resv_regions()` if DMA translation fails.
- [High] Incorrect iteration over `iommu-addresses` when a phandle does not match `dev->of_node`, causing parsing misalignment and out-of-bounds reads.
- [Medium] Pre-existing memory leak of `device_node` in `of_iommu_get_resv_regions()`.
--

--- Patch [9]: [PATCH 09/22] arm64: dts: qcom: sm8550: Reserve low IOVA range for Iris ---
commit b23293d9b1e601df9a40295b28db44388efa63a4
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sm8550: Reserve low IOVA range for Iris

This commit adds a reserved-memory IOVA reservation node for the Iris VPU to
keep IOMMU allocations above 0x25800000. It prevents SMMU page faults and
device reboots when DMA accesses that range. The new region is referenced
from the Iris node using the iommu-addresses property.

> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index 0e701e709235c..1eb725a584b26 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>;
> +		};

[Severity: High]
This is a pre-existing issue, but could introducing this iommu-addresses
property expose a panic in the device tree parsing logic?

In drivers/iommu/of_iommu.c:of_iommu_get_resv_regions(), if the DMA region
translation fails, the maps pointer is overwritten with a NULL pointer and
length is left uninitialized:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
				maps = of_translate_dma_region(np, maps, &iova, &length);
				if (length == 0) {
    ...
}

Because length is uninitialized stack memory, it might not be zero. 

The loop would then iterate again, and since maps is NULL and end is a valid
memory address, the loop condition is met and it attempts to dereference the
NULL pointer:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
		while (maps < end) {
			struct device_node *np;
			u32 phandle;

			phandle = be32_to_cpup(maps++);
    ...
}


[Severity: High]
This isn't a bug introduced by this patch, but does the IOMMU parsing logic
correctly advance the maps pointer when a phandle does not match?

When iterating over the properties, if the phandle does not match the active
device node, the maps pointer only advances by one cell:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
			np = of_find_node_by_phandle(phandle);

			if (np == dev->of_node) {
    ...
}

Without logic to advance maps past the address and size cells of the skipped
entry, subsequent iterations will mistakenly read the address or size data as
the next phandle, corrupting the array parsing and potentially causing an
out-of-bounds read.


[Severity: Medium]
This is a pre-existing issue, but is there a reference count leak for the
device node during this parsing loop?

Inside the same property parsing loop, a reference to the device node is
obtained:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
			np = of_find_node_by_phandle(phandle);
    ...
}

However, the loop iteration concludes without calling of_node_put() to drop
the reference:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
			}
		}
    ...
}

Would it be helpful to add an of_node_put(np) call after the entry is parsed
to prevent leaking the reference on each valid phandle?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=9

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Pre-existing parsing bug in `of_iommu_get_resv_regions()` causing misalignment and incorrect parsing when encountering non-matching shared reservations.
- [High] Missing NULL check for the return value of `of_translate_dma_region()` causes a kernel panic if address translation fails.
--

--- Patch [10]: [PATCH 10/22] arm64: dts: qcom: sm8650: Reserve low IOVA range for Iris ---
commit 0235003bbbcd1eb35cb1bdeb1f805b1bd98ddfd1
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sm8650: Reserve low IOVA range for Iris

Iris VPU reserves IOVA addresses below 0x25800000, primarily for secure
non-pixel buffers. This commit adds a reserved-memory IOVA reservation
node covering [0, 0x25800000] and references it from the Iris node to keep
DMA allocations above that boundary.

> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
[ ... ]
> @@ -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>;

[Severity: High]
This isn't a bug introduced by this patch, but does adding multiple entries
to a memory-region expose a parsing bug in of_iommu_get_resv_regions()?

When processing a node with multiple entries, if an earlier phandle in the
list does not match dev->of_node, the loop in drivers/iommu/of_iommu.c
fails to advance the maps pointer over the address and size cells:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    phandle = be32_to_cpup(maps++);
    np = of_find_node_by_phandle(phandle);

    if (np == dev->of_node) {
        ...
        maps = of_translate_dma_region(np, maps, &iova, &length);
        ...
    }
    /* Missing advancement of maps if np != dev->of_node */
}

Will the next iteration erroneously read the unparsed address or size cells
as the next phandle, corrupting the device tree parsing?

[Severity: High]
This is another pre-existing issue in the same parsing area, but could
address translation failures lead to a kernel panic here?

If of_translate_dma_region() fails (for example, if the device lacks a DMA
parent), it returns NULL. The return value is assigned directly to maps
without checking:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    maps = of_translate_dma_region(np, maps, &iova, &length);
    if (length == 0) {
    ...
}

On the next loop iteration, the condition maps < end will be evaluated
where NULL is less than the valid kernel pointer end, and
be32_to_cpup(maps++) will dereference the NULL pointer.

Could this trigger a crash on boot if an untranslatable DMA region is
encountered?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=10

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing error handling for `of_translate_dma_region` leads to uninitialized stack usage and a NULL pointer dereference.
- [High] The loop parsing `iommu-addresses` fails to advance the property pointer when skipping entries for other devices, corrupting parsing.
--

--- Patch [11]: [PATCH 11/22] arm64: dts: qcom: sm8750: Reserve low IOVA range for Iris ---
commit c7d055796e0d5e48c39a3d7938283d3a8d0628e4
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sm8750: Reserve low IOVA range for Iris

This commit adds a reserved-memory IOVA reservation node for the Iris VPU to 
keep IOMMU allocations above 0x25800000, preventing unhandled SMMU faults.
It also references the reservation node from the Iris node.

> diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
> index dd738d13df8e0..cf17c76a4a390 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>;
> +		};

[Severity: High]
This isn't a bug introduced by this patch, but using iommu-addresses here
exposes a NULL pointer dereference risk in drivers/iommu/of_iommu.c if the
device tree is ever misconfigured.

If of_translate_dma_region() fails (e.g., due to invalid dma-ranges), it
returns NULL, which is assigned directly to maps without checking:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    maps = of_translate_dma_region(np, maps, &iova, &length);
    ...
}

On the next loop iteration, maps is compared to end, and then dereferenced
via be32_to_cpup(maps++), causing a kernel oops and failing to boot:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    while (maps < end) {
        struct device_node *np;
        u32 phandle;

        phandle = be32_to_cpup(maps++);
    ...
}

In addition, length and iova remain uninitialized stack variables. Can we
add a check for NULL after of_translate_dma_region() to prevent this crash?

[Severity: High]
This is a pre-existing issue, but adding iommu-addresses here is affected by
a parsing bug in drivers/iommu/of_iommu.c for multi-entry properties.

When parsing the array, if the phandle does not match dev->of_node, the code
skips the if block and loops, but fails to advance past the DMA address and
size cells for the skipped entry:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
        if (np == dev->of_node) {
            int err;

            maps = of_translate_dma_region(np, maps, &iova, &length);
    ...
}

The next loop iteration will misinterpret the skipped DMA address as the next
phandle, corrupting the parsing entirely. Does this need to be fixed in
of_iommu_get_resv_regions() to safely support multi-entry iommu-addresses
properties?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=11

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Multiple parsing vulnerabilities in `of_iommu_get_resv_regions` when processing `iommu-addresses`.
--

--- Patch [12]: [PATCH 12/22] arm64: dts: qcom: agatti: Reserve low IOVA range for Venus ---
commit ce9067cc6b514ef4e9f906bcee46fa8222f6c18b
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: agatti: Reserve low IOVA range for Venus

This commit reserves IOVA addresses below 0x25800000 for the Venus VPU.
This prevents unhandled SMMU page faults and spontaneous reboots when
other stream IDs DMA into that range.

Fixes: 7a37bf31e3a7 ("arm64: dts: qcom: qcm2290: Add Venus video node")
Cc: stable@vger.kernel.org

> diff --git a/arch/arm64/boot/dts/qcom/agatti.dtsi b/arch/arm64/boot/dts/qcom/agatti.dtsi
> index 590bd2432d85b..6ae66ef882363 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>;
> +		};
[Severity: High]
This isn't a bug introduced by this patch, but using the iommu-addresses
property here exposes multiple parsing vulnerabilities in
of_iommu_get_resv_regions() in drivers/iommu/of_iommu.c.

First, if a memory-region specifies iommu-addresses with entries for
multiple devices, the loop reads the first phandle. If it doesn't match
dev->of_node, it continues without advancing the maps pointer by the
required address and size cells (na + ns):

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    phandle = be32_to_cpup(maps++);
    np = of_find_node_by_phandle(phandle);

    if (np == dev->of_node) {
        ...
}

Does this cause the next iteration to incorrectly interpret the remaining
address and size cells as a phandle?

Second, if of_translate_dma_region() fails because there is no DMA parent,
it returns null. The stack variable length remains uninitialized. If length
is not zero, the loop proceeds.

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    maps = of_translate_dma_region(np, maps, &iova, &length);
    if (length == 0)
        continue;
    ...
}

Since maps is null, will this trigger a fatal null pointer dereference on
the next maps++ ?

Finally, there appears to be no bounds check before of_translate_dma_region()
reads na + ns cells from the maps pointer.

Should these parser issues in of_iommu_get_resv_regions() be fixed before
or alongside introducing this iommu-addresses usage?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=12

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Fatal parsing bug and NULL pointer dereference in `of_iommu_get_resv_regions` when parsing `iommu-addresses`.
--

--- Patch [13]: [PATCH 13/22] arm64: dts: qcom: kodiak: Reserve low IOVA range for Venus ---
commit c5c55dfe3f391bbec75ef2147bce3c7b4d05e83b
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Subject: arm64: dts: qcom: kodiak: Reserve low IOVA range for Venus

This commit reserves IOVA addresses below 0x25800000 for the Venus VPU to
prevent SMMU page faults and spontaneous reboots caused by unhandled DMA.
It adds a reserved-memory IOVA reservation node and references it from the
venus node to keep IOMMU allocations above this boundary.

> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> --- 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>;

[Severity: High]
This isn't a bug introduced by this patch, but adding this iommu-addresses
property exposes a fatal parsing flaw in the IOMMU core layer that can panic
the kernel.

In drivers/iommu/of_iommu.c:of_iommu_get_resv_regions(), the loop parsing
the iommu-addresses property assigns the map pointer without validation:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    maps = of_translate_dma_region(np, maps, &iova, &length);
    ...
}

If of_translate_dma_region() fails, it returns NULL. The code does not
check for this, meaning maps becomes NULL. The loop condition (maps < end)
then evaluates to true, and the next iteration will directly dereference
NULL.

Additionally, if the parsed phandle does not match dev->of_node:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    if (np == dev->of_node) {
        // ...
    }
    ...
}

The code falls through without advancing the maps pointer to skip the
current device's address and size cells. This causes the next iteration to
incorrectly read address cells as phandles, entirely corrupting the DT
parsing structure.

Is there any risk that this new configuration could trigger a translation
failure or phandle mismatch during device probe and hit these bugs?

> +		};
>  	};
>  
>  	cpus {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=13

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The IOVA reservation added for Venus is ineffective because the qcom-iommu driver does not implement the `.get_resv_regions` callback.
--

--- Patch [14]: [PATCH 14/22] arm64: dts: qcom: msm8916: Reserve low IOVA range for Venus ---
commit d8c0142deff84cf404f92b187d9bada3c787a2bb
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: msm8916: Reserve low IOVA range for Venus

This commit reserves the IOVA address range below 0x25800000 for the
Venus VPU to prevent unhandled SMMU page faults and spontaneous reboots
during video decode. It adds a reserved-memory IOVA node and references
it in the venus node.

> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index e39743e220438..b9f63d9f2c775 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>;
> +		};

[Severity: High]
Is this reservation effective on this platform? 

Looking at the qcom-iommu driver used by apps_iommu, the qcom_iommu_ops
structure does not implement the .get_resv_regions callback:

drivers/iommu/arm/arm-smmu/qcom_iommu.c:qcom_iommu_ops {
	static const struct iommu_ops qcom_iommu_ops = {
		.identity_domain = &qcom_iommu_identity_domain,
		.capable         = qcom_iommu_capable,
		...
	};
}

Without this callback, iommu_get_resv_regions() will return an empty list
and silently ignore the iommu-addresses property defined in the device tree.

Could this allow the DMA API to continue allocating IOVA addresses in the
reserved range, thereby still triggering the SMMU faults and system reboots?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=14

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Flawed iteration and error handling in of_iommu_get_resv_regions() causes parser corruption and NULL pointer dereference.
--

--- Patch [17]: [PATCH 17/22] arm64: dts: qcom: sc7180: Reserve low IOVA range for Venus ---
commit dbfbcf45d9c413275eb757edbb4fc53e7e4ee11b
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sc7180: Reserve low IOVA range for Venus

This commit adds a reserved-memory IOVA node for the Venus VPU covering
the first 600MB. It references this node in the venus video-codec to keep
IOMMU allocations above this boundary and prevent spontaneous reboots
caused by unhandled SMMU page faults.

> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 70fbfb31d4a4d..4ea2dfe311039 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>;

[Severity: High]
This isn't a bug introduced by this patch, but adding this iommu-addresses
property exposes a pre-existing flaw in how drivers/iommu/of_iommu.c handles
parsing in of_iommu_get_resv_regions().

If a phandle does not match dev->of_node:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    while (maps < end) {
        ...
        phandle = be32_to_cpup(maps++);
        np = of_find_node_by_phandle(phandle);

        if (np == dev->of_node) {
    ...
}

Does the code fail to advance the maps pointer past the current entry's
address and size cells, corrupting subsequent parsing?

Additionally, if of_translate_dma_region() fails, it returns NULL:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
                maps = of_translate_dma_region(np, maps, &iova, &length);
                if (length == 0) {
                    dev_warn(dev, "Cannot reserve IOVA region of 0 size\n");
                    continue;
                }
    ...
}

Could this leave length and iova uninitialized and set maps to NULL, leading
to a NULL pointer dereference on the next loop iteration?

> +		};
>  	};

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=17

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Severe parsing flaws in `of_iommu_get_resv_regions()` lead to parser desynchronization, out-of-bounds reads, and a NULL pointer dereference when processing the `iommu-addresses` device tree property.
--

--- Patch [18]: [PATCH 18/22] arm64: dts: qcom: sdm630: Reserve low IOVA range for Venus ---
commit c911f79533bbf9fd3f531d014c6333ee5871bf3d
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sdm630: Reserve low IOVA range for Venus

This commit reserves IOVA addresses below 0x25800000 for the Venus VPU to
prevent unhandled SMMU page faults. It adds a reserved-memory IOVA
reservation node and references it from the venus node.

> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> index a41ba0da380bb..a80ae33f2c45c 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>;
> +		};
[Severity: High]
This is a pre-existing issue, but could this iommu-addresses property
trigger parsing flaws in of_iommu_get_resv_regions()?

Looking at drivers/iommu/of_iommu.c:of_iommu_get_resv_regions():

	while (maps < end) {
		struct device_node *np;
		u32 phandle;

		phandle = be32_to_cpup(maps++);
		np = of_find_node_by_phandle(phandle);

		if (np == dev->of_node) {

If np != dev->of_node, the loop fails to advance maps by the number
of address and size cells for the current phandle. This causes a parser
desynchronization on the next iteration.

Additionally, a few lines later:

		maps = of_translate_dma_region(np, maps, &iova, &length);
		if (length == 0) {

The unchecked NULL return from of_translate_dma_region() is assigned
directly to maps. The uninitialized length stack variable is then checked
instead of verifying the pointer.

If of_translate_dma_region() fails and returns NULL, it can lead to a
subsequent NULL pointer dereference in the next loop iteration.

>  	};
>  
>  	smem: smem {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=18

[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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Low] The `venus-iova` node lacks required `reg` or `size` properties and relies on an undocumented property, violating the `reserved-memory` schema.

Pre-existing issues:
- [High] Reference leak and parsing desync in `of_iommu_get_resv_regions` when parsing `iommu-addresses` for unmatched devices.
- [High] NULL pointer dereference in `of_iommu_get_resv_regions` if `of_translate_dma_region` fails.
--

--- Patch [20]: [PATCH 20/22] arm64: dts: qcom: sm6115: Reserve low IOVA range for Venus ---
commit bec476bec203ee86c0c6ea293d84bdd69fa09d6f
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: sm6115: Reserve low IOVA range for Venus

Venus VPU reserves IOVA addresses below 0x25800000 (600MB), primarily for
secure non-pixel buffers. Add a reserved-memory IOVA reservation node
covering [0, 0x25800000] and reference it from the venus node.

Cc: stable@vger.kernel.org

> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi
> index 3520802d1fed5..93f4eb8d18a71 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>;

[Severity: Low]
Will this fail devicetree validation tooling? The venus_iova node appears
to be missing the standard reg or size properties, and relies on the
undocumented iommu-addresses property, which might violate the core
reserved-memory devicetree schema.

[Severity: High]
This isn't a bug introduced by this patch, but using the iommu-addresses
property here exposes an existing reference leak and parsing desynchronization
in drivers/iommu/of_iommu.c:of_iommu_get_resv_regions().

If the property contains a phandle that does not match dev->of_node,
the node reference is leaked:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
            phandle = be32_to_cpup(maps++);
            np = of_find_node_by_phandle(phandle);

            if (np == dev->of_node) {
    ...
}

Because the if block is skipped for unmatched devices, of_node_put(np) is
never called. Furthermore, the maps pointer is not advanced past the device's
address and size cells. Would this cause the next loop iteration to read the
address/size as a phandle, corrupting all subsequent parsing?

[Severity: High]
This is also a pre-existing issue, but utilizing iommu-addresses here could
trigger a NULL pointer dereference in the same parsing function.

If of_translate_dma_region() returns NULL on a translation error (such as a
bad address or missing DMA parent):

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
                maps = of_translate_dma_region(np, maps, &iova, &length);
    ...
}

The maps pointer becomes NULL and is directly dereferenced in the next
iteration of the while loop. Could this cause a kernel panic during device
probe if the devicetree configuration is malformed?

> +		};
>  	};
>  
>  	smp2p-adsp {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=20

[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 22/22] arm64: dts: qcom: talos: Reserve low IOVA range for Venus

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the parsing loop in `of_iommu_get_resv_regions` fails to properly advance the `maps` pointer when a tuple's `phandle` does not match the target device, leading to corrupt parsing and potential out-of-bounds reads.
- [High] This problem wasn't introduced by this patch, but an unchecked return value from `of_translate_dma_region()` in `of_iommu_get_resv_regions()` leads to uninitialized stack variable usage and a NULL pointer dereference.
--

--- Patch [22]: [PATCH 22/22] arm64: dts: qcom: talos: Reserve low IOVA range for Venus ---
commit c79264714a3878505bc5105c9bc703dbf039cc23
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

arm64: dts: qcom: talos: Reserve low IOVA range for Venus

This commit adds a reserved-memory IOVA reservation node for the Venus VPU
and references it to keep DMA allocations above 0x25800000. This prevents
unhandled SMMU page faults and spontaneous device reboots.

> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
> index eedfdce3c479e..8645b04e26643 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>;

[Severity: High]
This isn't a bug introduced by this patch, but does adding an
iommu-addresses property expose an existing parsing issue in
of_iommu_get_resv_regions()?

When parsing the iommu-addresses property, if a tuple's phandle does not
match dev->of_node, the loop skips the match block but fails to properly
advance the maps pointer past the current tuple's address and size cells:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    while (maps < end) {
        phandle = be32_to_cpup(maps++);
        np = of_find_node_by_phandle(phandle);
        
        if (np == dev->of_node) {
            ...
        }
        /* maps is not advanced by address/size cells if np != dev->of_node */
    }
    ...
}

Could this lead to the next iteration incorrectly treating part of the DMA
address as the next phandle, resulting in out-of-bounds reads or corrupt
parsing?

[Severity: High]
This is also a pre-existing issue, but could parsing this property lead to a
NULL pointer dereference if of_translate_dma_region() fails?

If of_translate_dma_region() returns NULL (e.g. due to missing dma-ranges
or a malformed DT), the return value is assigned directly to maps without
a NULL check:

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    maps = of_translate_dma_region(np, maps, &iova, &length);
    if (length == 0) {
    ...
}

Since length is evaluated without initialization if the translation fails,
and maps becomes NULL, could the subsequent loop iteration dereference the
NULL maps pointer when reading the next phandle?

drivers/iommu/of_iommu.c:of_iommu_get_resv_regions() {
    ...
    while (maps < end) {
        phandle = be32_to_cpup(maps++);
    ...
}

> +		};
>  	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-iris_iova_600mb_fix-v1-0-3996f67e33f9@oss.qualcomm.com?part=22

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 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 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