[PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Vishnu Reddy]

Drivers can create child devices dynamically. These child devices often
inherit parent device tree node, including its reserved iommu-address
ranges. While device tree can declare the multiple iommu-address ranges,
they still apply uniformly to any child inheriting the parent OF node.

This creates a limitation when child requires a different iommu-address
range than its parent, as device tree cannot express the reservation per
child.

Example layout and use case:
----------------------------
A multimedia subsystem with multiple child devices and distinct ranges:

    +-----------------------------------------------------------+
    | Device A reserved region (256 MB)                         |
    | 0x00000000 - 0x10000000                                   |
    +-----------------------------------------------------------+
    | Device B reserved region (512 MB)                         |
    | 0x00000000 - 0x20000000                                   |
    +-----------------------------------------------------------+
    | Device C reserved region (600 MB)                         |
    | 0x00000000 - 0x25800000                                   |
    +-----------------------------------------------------------+
    | Other reserved regions                                    |
    +-----------------------------------------------------------+

If we add Device C's reserved range (0x0 to 0x025800000) into iommu
address range into device tree and assign that OF node to Device B
and C, it wastes memory:
- Device A wastes ~344 MB
- Device B wastes ~88 MB

To avoid this, drivers can use the introduced API to set their device
specific IOVA region at runtime, ensuring the DMA mapping without
unnecessary address space reservation.

Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20251220023555.3017456-1-busanna.reddy@oss.qualcomm.com/
---
 drivers/iommu/dma-iommu.c   | 44 +++++++++++++++++++++++++++++++++++++
 include/linux/dma-mapping.h |  7 ++++++
 2 files changed, 51 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index aeaf8fad985c3..baee119e1c277 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1743,6 +1743,50 @@ size_t iommu_dma_max_mapping_size(struct device *dev)
 	return SIZE_MAX;
 }
 
+/**
+ * dma_iova_set_resv_region - Set a reserved region in the IOVA space
+ * @dev: Device to set the reserved region for
+ * @start: Start of the reserved region
+ * @length: Length of the reserved region
+ *
+ * This function enables drivers to set device specific reservations at
+ * runtime, which is particularly useful for dynamically created child
+ * devices that requires distinct IOVA ranges than parent.
+ *
+ * Returns:
+ *  0        - Success
+ *  -ENODEV  - No valid IOMMU DMA domain for the device
+ *  -EINVAL  - Invalid domain or cookie type for this operation
+ *  -ENOMEM  - Failed to reserve the requested range
+ */
+int dma_iova_set_resv_region(struct device *dev, unsigned long start,
+			     unsigned long length)
+{
+	struct iommu_dma_cookie *cookie;
+	struct iommu_domain *domain;
+	struct iova_domain *iovad;
+	unsigned long lo, hi;
+
+	domain = iommu_get_dma_domain(dev);
+	if (!domain || domain->type != IOMMU_DOMAIN_DMA)
+		return -ENODEV;
+
+	cookie = domain->iova_cookie;
+	if (!cookie || domain->cookie_type != IOMMU_COOKIE_DMA_IOVA)
+		return -EINVAL;
+
+	iovad = &cookie->iovad;
+
+	lo = iova_pfn(iovad, start);
+	hi = iova_pfn(iovad, start + length - 1);
+
+	if (!reserve_iova(iovad, lo, hi))
+		return -ENOMEM;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(dma_iova_set_resv_region);
+
 /**
  * dma_iova_try_alloc - Try to allocate an IOVA space
  * @dev: Device to allocate the IOVA space for
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 29973baa05816..75b65160a37f3 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -347,6 +347,8 @@ static inline bool dma_use_iova(struct dma_iova_state *state)
 	return state->__size != 0;
 }
 
+int dma_iova_set_resv_region(struct device *dev, unsigned long start,
+			     unsigned long length);
 bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state,
 		phys_addr_t phys, size_t size);
 void dma_iova_free(struct device *dev, struct dma_iova_state *state);
@@ -366,6 +368,11 @@ static inline bool dma_use_iova(struct dma_iova_state *state)
 {
 	return false;
 }
+static inline int dma_iova_set_resv_region(struct device *dev, unsigned long start,
+					   unsigned long length)
+{
+	return -ENODEV;
+}
 static inline bool dma_iova_try_alloc(struct device *dev,
 		struct dma_iova_state *state, phys_addr_t phys, size_t size)
 {
-- 
2.34.1

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Christoph Hellwig]

This still seems to lack an actual user.

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Robin Murphy]

On 19/01/2026 5:49 am, Vishnu Reddy wrote:
> Drivers can create child devices dynamically. These child devices often
> inherit parent device tree node, including its reserved iommu-address
> ranges.

Which frankly sounds entirely wrong. If there are distinct devices with 
distinct hardware properties, then they should be properly described as 
such, and handled by a proper bus driver. And if different devices have 
different DMA restrictions, that should be described by "dma-ranges", 
not by abusing reserved regions.

Thanks,
Robin.

> While device tree can declare the multiple iommu-address ranges,
> they still apply uniformly to any child inheriting the parent OF node.
> 
> This creates a limitation when child requires a different iommu-address
> range than its parent, as device tree cannot express the reservation per
> child.
> 
> Example layout and use case:
> ----------------------------
> A multimedia subsystem with multiple child devices and distinct ranges:
> 
>      +-----------------------------------------------------------+
>      | Device A reserved region (256 MB)                         |
>      | 0x00000000 - 0x10000000                                   |
>      +-----------------------------------------------------------+
>      | Device B reserved region (512 MB)                         |
>      | 0x00000000 - 0x20000000                                   |
>      +-----------------------------------------------------------+
>      | Device C reserved region (600 MB)                         |
>      | 0x00000000 - 0x25800000                                   |
>      +-----------------------------------------------------------+
>      | Other reserved regions                                    |
>      +-----------------------------------------------------------+
> 
> If we add Device C's reserved range (0x0 to 0x025800000) into iommu
> address range into device tree and assign that OF node to Device B
> and C, it wastes memory:
> - Device A wastes ~344 MB
> - Device B wastes ~88 MB
> 
> To avoid this, drivers can use the introduced API to set their device
> specific IOVA region at runtime, ensuring the DMA mapping without
> unnecessary address space reservation.
> 
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Link: https://lore.kernel.org/all/20251220023555.3017456-1-busanna.reddy@oss.qualcomm.com/
> ---
>   drivers/iommu/dma-iommu.c   | 44 +++++++++++++++++++++++++++++++++++++
>   include/linux/dma-mapping.h |  7 ++++++
>   2 files changed, 51 insertions(+)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index aeaf8fad985c3..baee119e1c277 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -1743,6 +1743,50 @@ size_t iommu_dma_max_mapping_size(struct device *dev)
>   	return SIZE_MAX;
>   }
>   
> +/**
> + * dma_iova_set_resv_region - Set a reserved region in the IOVA space
> + * @dev: Device to set the reserved region for
> + * @start: Start of the reserved region
> + * @length: Length of the reserved region
> + *
> + * This function enables drivers to set device specific reservations at
> + * runtime, which is particularly useful for dynamically created child
> + * devices that requires distinct IOVA ranges than parent.
> + *
> + * Returns:
> + *  0        - Success
> + *  -ENODEV  - No valid IOMMU DMA domain for the device
> + *  -EINVAL  - Invalid domain or cookie type for this operation
> + *  -ENOMEM  - Failed to reserve the requested range
> + */
> +int dma_iova_set_resv_region(struct device *dev, unsigned long start,
> +			     unsigned long length)
> +{
> +	struct iommu_dma_cookie *cookie;
> +	struct iommu_domain *domain;
> +	struct iova_domain *iovad;
> +	unsigned long lo, hi;
> +
> +	domain = iommu_get_dma_domain(dev);
> +	if (!domain || domain->type != IOMMU_DOMAIN_DMA)
> +		return -ENODEV;
> +
> +	cookie = domain->iova_cookie;
> +	if (!cookie || domain->cookie_type != IOMMU_COOKIE_DMA_IOVA)
> +		return -EINVAL;
> +
> +	iovad = &cookie->iovad;
> +
> +	lo = iova_pfn(iovad, start);
> +	hi = iova_pfn(iovad, start + length - 1);
> +
> +	if (!reserve_iova(iovad, lo, hi))
> +		return -ENOMEM;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(dma_iova_set_resv_region);
> +
>   /**
>    * dma_iova_try_alloc - Try to allocate an IOVA space
>    * @dev: Device to allocate the IOVA space for
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 29973baa05816..75b65160a37f3 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -347,6 +347,8 @@ static inline bool dma_use_iova(struct dma_iova_state *state)
>   	return state->__size != 0;
>   }
>   
> +int dma_iova_set_resv_region(struct device *dev, unsigned long start,
> +			     unsigned long length);
>   bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state,
>   		phys_addr_t phys, size_t size);
>   void dma_iova_free(struct device *dev, struct dma_iova_state *state);
> @@ -366,6 +368,11 @@ static inline bool dma_use_iova(struct dma_iova_state *state)
>   {
>   	return false;
>   }
> +static inline int dma_iova_set_resv_region(struct device *dev, unsigned long start,
> +					   unsigned long length)
> +{
> +	return -ENODEV;
> +}
>   static inline bool dma_iova_try_alloc(struct device *dev,
>   		struct dma_iova_state *state, phys_addr_t phys, size_t size)
>   {

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Vishnu Reddy]

On 1/19/2026 7:43 PM, Robin Murphy wrote:
> On 19/01/2026 5:49 am, Vishnu Reddy wrote:
>> Drivers can create child devices dynamically. These child devices often
>> inherit parent device tree node, including its reserved iommu-address
>> ranges.
>
> Which frankly sounds entirely wrong. If there are distinct devices with
> distinct hardware properties, then they should be properly described as such,
> and handled by a proper bus driver. And if different devices have different
> DMA restrictions, that should be described by "dma-ranges", not by abusing
> reserved regions.
>

Hi Robin,

The VPU is a single hardware unit, but internally it consists of
multiple functional blocks. Each block has its own distinct Stream ID
(SID) and operates with a different IOVA range requirement:

  +--------------------------------------------------+
  |                  VPU Hardware                    |
  |                                                  |
  |  +------------+   SID-0   IOVA: 600MB - 3500MB   |
  |  |  Block 0   |                                  |
  |  +------------+                                  |
  |                                                  |
  |  +------------+   SID-1   IOVA: 0MB  - 3500MB    |
  |  |  Block 1   |                                  |
  |  +------------+                                  |
  |                                                  |
  |  +------------+   SID-2   IOVA: 16MB - 600MB     |
  |  |  Block 2   |                                  |
  |  +------------+                                  |
  +--------------------------------------------------+

Each Stream ID maps to a distinct IOMMU context bank, and each context
bank enforces a different IOVA range.

The upper boundary can be enforced via dma_set_mask_and_coherent. However,
enforcing the lower boundary (e.g., blocking 0 to 600MB for Block 0,
and 0 to 16MB for Block 2) requires explicit IOVA reservation,
which is what dma_iova_set_resv_region() provides in this patch.

These are synthetic child devices created at runtime and do not have their
own of_node. Inheriting the parent of_node might not be the correct way.

A crash was observed on one of the platforms due to the absence of
reserved regions. This API would help avoid such crashes by allowing
drivers to explicitly reserve the restricted IOVA range.
https://gitlab.freedesktop.org/drm/msm/-/work_items/100

Thanks,
Vishnu Reddy.

> Thanks,
> Robin.
>
>> While device tree can declare the multiple iommu-address ranges,
>> they still apply uniformly to any child inheriting the parent OF node.
>>
>> This creates a limitation when child requires a different iommu-address
>> range than its parent, as device tree cannot express the reservation per
>> child.
>>
>> Example layout and use case:
>> ----------------------------
>> A multimedia subsystem with multiple child devices and distinct ranges:
>>
>>      +-----------------------------------------------------------+
>>      | Device A reserved region (256 MB)                         |
>>      | 0x00000000 - 0x10000000                                   |
>>      +-----------------------------------------------------------+
>>      | Device B reserved region (512 MB)                         |
>>      | 0x00000000 - 0x20000000                                   |
>>      +-----------------------------------------------------------+
>>      | Device C reserved region (600 MB)                         |
>>      | 0x00000000 - 0x25800000                                   |
>>      +-----------------------------------------------------------+
>>      | Other reserved regions                                    |
>>      +-----------------------------------------------------------+
>>
>> If we add Device C's reserved range (0x0 to 0x025800000) into iommu
>> address range into device tree and assign that OF node to Device B
>> and C, it wastes memory:
>> - Device A wastes ~344 MB
>> - Device B wastes ~88 MB
>>
>> To avoid this, drivers can use the introduced API to set their device
>> specific IOVA region at runtime, ensuring the DMA mapping without
>> unnecessary address space reservation.
>>
>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Link:
>> https://lore.kernel.org/all/20251220023555.3017456-1-busanna.reddy@oss.qualcomm.com/
>> ---
>>   drivers/iommu/dma-iommu.c   | 44 +++++++++++++++++++++++++++++++++++++
>>   include/linux/dma-mapping.h |  7 ++++++
>>   2 files changed, 51 insertions(+)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index aeaf8fad985c3..baee119e1c277 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -1743,6 +1743,50 @@ size_t iommu_dma_max_mapping_size(struct device *dev)
>>       return SIZE_MAX;
>>   }
>>   +/**
>> + * dma_iova_set_resv_region - Set a reserved region in the IOVA space
>> + * @dev: Device to set the reserved region for
>> + * @start: Start of the reserved region
>> + * @length: Length of the reserved region
>> + *
>> + * This function enables drivers to set device specific reservations at
>> + * runtime, which is particularly useful for dynamically created child
>> + * devices that requires distinct IOVA ranges than parent.
>> + *
>> + * Returns:
>> + *  0        - Success
>> + *  -ENODEV  - No valid IOMMU DMA domain for the device
>> + *  -EINVAL  - Invalid domain or cookie type for this operation
>> + *  -ENOMEM  - Failed to reserve the requested range
>> + */
>> +int dma_iova_set_resv_region(struct device *dev, unsigned long start,
>> +                 unsigned long length)
>> +{
>> +    struct iommu_dma_cookie *cookie;
>> +    struct iommu_domain *domain;
>> +    struct iova_domain *iovad;
>> +    unsigned long lo, hi;
>> +
>> +    domain = iommu_get_dma_domain(dev);
>> +    if (!domain || domain->type != IOMMU_DOMAIN_DMA)
>> +        return -ENODEV;
>> +
>> +    cookie = domain->iova_cookie;
>> +    if (!cookie || domain->cookie_type != IOMMU_COOKIE_DMA_IOVA)
>> +        return -EINVAL;
>> +
>> +    iovad = &cookie->iovad;
>> +
>> +    lo = iova_pfn(iovad, start);
>> +    hi = iova_pfn(iovad, start + length - 1);
>> +
>> +    if (!reserve_iova(iovad, lo, hi))
>> +        return -ENOMEM;
>> +
>> +    return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(dma_iova_set_resv_region);
>> +
>>   /**
>>    * dma_iova_try_alloc - Try to allocate an IOVA space
>>    * @dev: Device to allocate the IOVA space for
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index 29973baa05816..75b65160a37f3 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -347,6 +347,8 @@ static inline bool dma_use_iova(struct dma_iova_state
>> *state)
>>       return state->__size != 0;
>>   }
>>   +int dma_iova_set_resv_region(struct device *dev, unsigned long start,
>> +                 unsigned long length);
>>   bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state,
>>           phys_addr_t phys, size_t size);
>>   void dma_iova_free(struct device *dev, struct dma_iova_state *state);
>> @@ -366,6 +368,11 @@ static inline bool dma_use_iova(struct dma_iova_state
>> *state)
>>   {
>>       return false;
>>   }
>> +static inline int dma_iova_set_resv_region(struct device *dev, unsigned long
>> start,
>> +                       unsigned long length)
>> +{
>> +    return -ENODEV;
>> +}
>>   static inline bool dma_iova_try_alloc(struct device *dev,
>>           struct dma_iova_state *state, phys_addr_t phys, size_t size)
>>   {
>

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Jason Gunthorpe]

On Wed, Jun 10, 2026 at 07:57:50PM +0530, Vishnu Reddy wrote:

>   +--------------------------------------------------+
>   |                  VPU Hardware                    |
>   |                                                  |
>   |  +------------+   SID-0   IOVA: 600MB - 3500MB   |
>   |  |  Block 0   |                                  |
>   |  +------------+                                  |
>   |                                                  |
>   |  +------------+   SID-1   IOVA: 0MB  - 3500MB    |
>   |  |  Block 1   |                                  |
>   |  +------------+                                  |
>   |                                                  |
>   |  +------------+   SID-2   IOVA: 16MB - 600MB     |
>   |  |  Block 2   |                                  |
>   |  +------------+                                  |
>   +--------------------------------------------------+
> 
> Each Stream ID maps to a distinct IOMMU context bank, and each context
> bank enforces a different IOVA range.

I think Robin is saying you have to describe your HW properly in
device tree. In Linux a single struct device should not own multiple
*different* IOMMU contexts.

So your DT should describe all those blocks as unique DT nodes with
the proper dma ranges and related data so they can do DMA
correctly. Then the parent device has to assemble itself from that
collection of struct devices.

> These are synthetic child devices created at runtime and do not have their
> own of_node. Inheriting the parent of_node might not be the correct way.

Why would you create child devices at runtime? Linux doesn't really
have a good way to create a fully DMA capable struct device at runtime
without a DT backing description. The fact you immediately hit API
problems like this is a big clue :)

Jason

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Vikash Garodia]

On 6/12/2026 10:56 PM, Jason Gunthorpe wrote:
> On Wed, Jun 10, 2026 at 07:57:50PM +0530, Vishnu Reddy wrote:
> 
>>    +--------------------------------------------------+
>>    |                  VPU Hardware                    |
>>    |                                                  |
>>    |  +------------+   SID-0   IOVA: 600MB - 3500MB   |
>>    |  |  Block 0   |                                  |
>>    |  +------------+                                  |
>>    |                                                  |
>>    |  +------------+   SID-1   IOVA: 0MB  - 3500MB    |
>>    |  |  Block 1   |                                  |
>>    |  +------------+                                  |
>>    |                                                  |
>>    |  +------------+   SID-2   IOVA: 16MB - 600MB     |
>>    |  |  Block 2   |                                  |
>>    |  +------------+                                  |
>>    +--------------------------------------------------+
>>
>> Each Stream ID maps to a distinct IOMMU context bank, and each context
>> bank enforces a different IOVA range.
> 
> I think Robin is saying you have to describe your HW properly in
> device tree. In Linux a single struct device should not own multiple
> *different* IOMMU contexts.
> 
> So your DT should describe all those blocks as unique DT nodes with
> the proper dma ranges and related data so they can do DMA
> correctly. Then the parent device has to assemble itself from that
> collection of struct devices.

For VPUs, these devices(or blocks) shares everything with the parent 
except the IOVA aspects associated with the stream-IDs from these block, 
something like

Iris {
   reg = <>;
   interrupts = <>;

   block1 {
     iommus = <>
     iommu-addresses = <>;
   }

   block2 {
     iommus = <>
     iommu-addresses = <>;
   }
.....
....
   blockN {
     iommus = <>
     iommu-addresses = <>;
   }

}

To handle such case, we create the device dynamically and associated the 
distinct IOVA range to them,via the api introduced in this patch.
This was prototyped in recent SOC here [1]

[1] 
https://lore.kernel.org/linux-media/20260313-kaanapali-iris-v3-1-9c0d1a67af4b@oss.qualcomm.com/

> 
>> These are synthetic child devices created at runtime and do not have their
>> own of_node. Inheriting the parent of_node might not be the correct way.
> 
> Why would you create child devices at runtime? Linux doesn't really
> have a good way to create a fully DMA capable struct device at runtime
> without a DT backing description. The fact you immediately hit API
> problems like this is a big clue :)

Other than this API to associate the iova, i think we did not hit any 
other problem so far.

Regards,
Vikash

> 
> Jason

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Jason Gunthorpe]

On Mon, Jun 15, 2026 at 12:26:25PM +0530, Vikash Garodia wrote:

> To handle such case, we create the device dynamically and associated the
> distinct IOVA range to them,via the api introduced in this patch.
> This was prototyped in recent SOC here [1]
> 
> [1] https://lore.kernel.org/linux-media/20260313-kaanapali-iris-v3-1-9c0d1a67af4b@oss.qualcomm.com/

Well, I'm not enthused by this:

+static int iris_vpu_bus_dma_configure(struct device *dev)
+{
+       struct iris_context_bank *cb = dev_get_drvdata(dev);
+
+       if (!cb)
+               return -ENODEV;
+
+       return of_dma_configure_id(dev, dev->parent->of_node, true, &cb->f_id);
+}

A custom bus and then calling configure_id on the parent which would
have already called of_dma_configure on that same of_node seems very
hacky to me.

Jason

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Vishnu Reddy]

On 6/15/2026 6:22 PM, Jason Gunthorpe wrote:
> On Mon, Jun 15, 2026 at 12:26:25PM +0530, Vikash Garodia wrote:
>
>> To handle such case, we create the device dynamically and associated the
>> distinct IOVA range to them,via the api introduced in this patch.
>> This was prototyped in recent SOC here [1]
>>
>> [1] https://lore.kernel.org/linux-media/20260313-kaanapali-iris-v3-1-9c0d1a67af4b@oss.qualcomm.com/
> Well, I'm not enthused by this:
>
> +static int iris_vpu_bus_dma_configure(struct device *dev)
> +{
> +       struct iris_context_bank *cb = dev_get_drvdata(dev);
> +
> +       if (!cb)
> +               return -ENODEV;
> +
> +       return of_dma_configure_id(dev, dev->parent->of_node, true, &cb->f_id);
> +}
>
> A custom bus and then calling configure_id on the parent which would
> have already called of_dma_configure on that same of_node seems very
> hacky to me.

Hi Jason,

Here, the parent node does not have an iommus property — it only has iommu-map,
like example below:

iommu-map = <0x0 &apps_smmu 0x1940 0x0 0x1>,  /* function_id 0 → SID 0x1940 */
            <0x1 &apps_smmu 0x1943 0x0 0x1>,  /* function_id 1 → SID 0x1943 */
            <0x2 &apps_smmu 0x1944 0x0 0x1>;  /* function_id 2 → SID 0x1944 */

When the parent device is probed, of_dma_configure() is called, which
internally invokes of_dma_configure_id() with NULL as the function ID. Since
there is no iommus entry, no stream ID gets mapped to the parent device.

The child devices are created at runtime and have no of_node of their own. The
only place the iommu-map property exists is on the parent's of_node. So when
configuring a child device, we pass the parent's of_node along with the child's
specific function_id — this is how of_dma_configure_id() finds and maps the
correct stream ID to the child device only.

So to be clear — the parent of_node is not being configured again. It is just
being used as a lookup source for the iommu-map property, since the child has
no of_node of its own.

Thanks,
Vishnu Reddy.

> Jason

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Jason Gunthorpe]

On Mon, Jun 15, 2026 at 11:21:45PM +0530, Vishnu Reddy wrote:
> Hi Jason,
> 
> Here, the parent node does not have an iommus property — it only has iommu-map,
> like example below:
> 
> iommu-map = <0x0 &apps_smmu 0x1940 0x0 0x1>,  /* function_id 0 → SID 0x1940 */
>             <0x1 &apps_smmu 0x1943 0x0 0x1>,  /* function_id 1 → SID 0x1943 */
>             <0x2 &apps_smmu 0x1944 0x0 0x1>;  /* function_id 2 → SID 0x1944 */
> 
> When the parent device is probed, of_dma_configure() is called, which
> internally invokes of_dma_configure_id() with NULL as the function ID. Since
> there is no iommus entry, no stream ID gets mapped to the parent device.

Sure, but it still did of_dma_configure on the parent..

> The child devices are created at runtime and have no of_node of their own. The
> only place the iommu-map property exists is on the parent's of_node. So when
> configuring a child device, we pass the parent's of_node along with the child's
> specific function_id — this is how of_dma_configure_id() finds and maps the
> correct stream ID to the child device only.

The whole thing seems like the wrong way to use DT to me. Having an
iommu-map in the dt that no iommus property ever uses strikes me as
abusive.

Then hard coding the ID table and manually creating the missing
struct devices in C code is a throw back to board files :(

Of course it doesn't fully work, it was never intended to be used like
this.

Why the resistance to doing DT properly with actual iommus and dma
ranges for each and every stream your device needs?

Jason

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Krzysztof Kozlowski]

On 17/06/2026 21:40, Jason Gunthorpe wrote:
> On Mon, Jun 15, 2026 at 11:21:45PM +0530, Vishnu Reddy wrote:
>> Hi Jason,
>>
>> Here, the parent node does not have an iommus property — it only has iommu-map,
>> like example below:
>>
>> iommu-map = <0x0 &apps_smmu 0x1940 0x0 0x1>,  /* function_id 0 → SID 0x1940 */
>>             <0x1 &apps_smmu 0x1943 0x0 0x1>,  /* function_id 1 → SID 0x1943 */
>>             <0x2 &apps_smmu 0x1944 0x0 0x1>;  /* function_id 2 → SID 0x1944 */
>>
>> When the parent device is probed, of_dma_configure() is called, which
>> internally invokes of_dma_configure_id() with NULL as the function ID. Since
>> there is no iommus entry, no stream ID gets mapped to the parent device.
> 
> Sure, but it still did of_dma_configure on the parent..
> 
>> The child devices are created at runtime and have no of_node of their own. The
>> only place the iommu-map property exists is on the parent's of_node. So when
>> configuring a child device, we pass the parent's of_node along with the child's
>> specific function_id — this is how of_dma_configure_id() finds and maps the
>> correct stream ID to the child device only.
> 
> The whole thing seems like the wrong way to use DT to me. Having an
> iommu-map in the dt that no iommus property ever uses strikes me as
> abusive.

Same with interrupt-map.

There are PCIe controller nodes which have interrupt-map and no
interrupts property ever uses them.

https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/freescale/imx8mm.dtsi?h=v7.1#n1340

There might be DT children but they still won't have interrupts at all.

> 
> Then hard coding the ID table and manually creating the missing
> struct devices in C code is a throw back to board files :(

There are no distinctive, specific child devices here. Devices in terms
of hardware. There are no resources of children, they are not real
hardware devices.

You mentioned earlier that DT description is incomplete or not proper. I
disagree. Adding any child here just to configure IOMMU differently is
abuse of DT - creating fake device nodes to overcome somehow Linux
limitations.

> 
> Of course it doesn't fully work, it was never intended to be used like
> this.
> 
> Why the resistance to doing DT properly with actual iommus and dma
> ranges for each and every stream your device needs?

Because DT person - me - told that creating child device nodes just to
configure iommus is abuse of DT. There are no child devices in terms of
hardware or firmware. The iommu ranges here are no real hardware.

However, said all this, since I pushed folks to come with the iommu-map
approach, I will revoke my disagreement to child device nodes in DT, if
you really believe that is the approach. IOW, I will agree to device
nodes in DT representing fake hardware-children, just for the sake of
Linux driver model limitations.


Best regards,
Krzysztof

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Jason Gunthorpe]

On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote:

> Same with interrupt-map.

> There are PCIe controller nodes which have interrupt-map and no
> interrupts property ever uses them.

PCIe is quite a different situation because we expect Linux to
dynamically create the child nodes based on PCIe discovery, and the
various maps are all searched based on the PCI BDF based on HW
properties of real discovered child devices.

Here they created "vpu_bus" and create a bunch of devices for some
reason, but they are all hard coded in the driver. It is not a dynamic
discovery, and it is not creating "real" child devices.

> Because DT person - me - told that creating child device nodes just to
> configure iommus is abuse of DT. There are no child devices in terms of
> hardware or firmware. The iommu ranges here are no real hardware.

That doesn't seem to be what Vishnu is saying. Review the earlier two
emails explaining what the HW issue is here:

https://lore.kernel.org/all/bb59f07e-ca7e-f012-6a4b-0a148350b69c@oss.qualcomm.com/
https://lore.kernel.org/all/cb37e7cc-4fb0-4c24-8f89-f6f9eb08a107@oss.qualcomm.com/

The VPU HW diagram with different IOVA requirements for different
stream IDs seems to be an entirely HW based thing: "each context bank
enforces a different IOVA range"

The original patches just created a 0 based IOVA space per stream and
justified that by increasing the IOVA address space (make sense). The
email above now says some of the streams only function with a limited
range of IOVA because the HW uses the IOVA itself to select the
streams (insane!)

IOW this entire device is completely mis-designed if it is going to
easially support the Linux DMA API :( That's all HW mess, which is
motivating hacks to try to make the Linux DMA API do something usable
by this device.

Anyhow..

In Linux if you use DT iommus the SW sets things up so every stream
shares the same translation. If your driver/device doesn't like that
there is no SW way to opt out of sharing. I think that is the first
core issue that VPU was struggling with.

If you have one "device" then I would argue the DT should describe all
its streams using iommus in the normal way. The introduction of
iommu-map for VPU is only being done because that is a convenient hack
to allow Linux to unbundle the streams. It would be much harder to
unbunble the streams directly from the DT iommus property, but that
would probably be the cleanest, software agnostic, DT modeling.

So, if we are going to do a hack in DT to accomodate Linux, I argue to
choose explicit child devices so VPU does not need to create a special
bus, call of_dma_configue, or hack in new DMA API things that only it
will ever use. Then the explicit children can properly describe how
the HW decodes IOVA into each streams in the DT (which sounds very
much like a HW property to me) so that Linux produces IOVA that the HW
mangling properly routes to the expected stream.

Then the VPU driver just has to assemble itself from many struct
devices, which I admit is also a troublesome task.

> However, said all this, since I pushed folks to come with the iommu-map
> approach, I will revoke my disagreement to child device nodes in DT, if
> you really believe that is the approach. IOW, I will agree to device
> nodes in DT representing fake hardware-children, just for the sake of
> Linux driver model limitations.

I would wait for Robin, he knows this better, but I belive this was
broadly his point in the original email..

Jason

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Krzysztof Kozlowski]

On 18/06/2026 17:17, Jason Gunthorpe wrote:
> On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote:
> 
>> Same with interrupt-map.
> 
>> There are PCIe controller nodes which have interrupt-map and no
>> interrupts property ever uses them.
> 
> PCIe is quite a different situation because we expect Linux to
> dynamically create the child nodes based on PCIe discovery, and the
> various maps are all searched based on the PCI BDF based on HW
> properties of real discovered child devices.
> 
> Here they created "vpu_bus" and create a bunch of devices for some
> reason, but they are all hard coded in the driver. It is not a dynamic
> discovery, and it is not creating "real" child devices.

Yes, true.

> 
>> Because DT person - me - told that creating child device nodes just to
>> configure iommus is abuse of DT. There are no child devices in terms of
>> hardware or firmware. The iommu ranges here are no real hardware.
> 
> That doesn't seem to be what Vishnu is saying. Review the earlier two
> emails explaining what the HW issue is here:
> 
> https://lore.kernel.org/all/bb59f07e-ca7e-f012-6a4b-0a148350b69c@oss.qualcomm.com/
> https://lore.kernel.org/all/cb37e7cc-4fb0-4c24-8f89-f6f9eb08a107@oss.qualcomm.com/
> 
> The VPU HW diagram with different IOVA requirements for different
> stream IDs seems to be an entirely HW based thing: "each context bank
> enforces a different IOVA range"
> 
> The original patches just created a 0 based IOVA space per stream and
> justified that by increasing the IOVA address space (make sense). The
> email above now says some of the streams only function with a limited
> range of IOVA because the HW uses the IOVA itself to select the
> streams (insane!)
> 
> IOW this entire device is completely mis-designed if it is going to
> easially support the Linux DMA API :( That's all HW mess, which is
> motivating hacks to try to make the Linux DMA API do something usable
> by this device.
> 
> Anyhow..
> 
> In Linux if you use DT iommus the SW sets things up so every stream
> shares the same translation. If your driver/device doesn't like that
> there is no SW way to opt out of sharing. I think that is the first
> core issue that VPU was struggling with.
> 
> If you have one "device" then I would argue the DT should describe all
> its streams using iommus in the normal way. The introduction of
> iommu-map for VPU is only being done because that is a convenient hack
> to allow Linux to unbundle the streams. It would be much harder to
> unbunble the streams directly from the DT iommus property, but that
> would probably be the cleanest, software agnostic, DT modeling.
> 
> So, if we are going to do a hack in DT to accomodate Linux, I argue to
> choose explicit child devices so VPU does not need to create a special
> bus, call of_dma_configue, or hack in new DMA API things that only it
> will ever use. Then the explicit children can properly describe how
> the HW decodes IOVA into each streams in the DT (which sounds very
> much like a HW property to me) so that Linux produces IOVA that the HW
> mangling properly routes to the expected stream.
> 
> Then the VPU driver just has to assemble itself from many struct
> devices, which I admit is also a troublesome task.
> 
>> However, said all this, since I pushed folks to come with the iommu-map
>> approach, I will revoke my disagreement to child device nodes in DT, if
>> you really believe that is the approach. IOW, I will agree to device
>> nodes in DT representing fake hardware-children, just for the sake of
>> Linux driver model limitations.
> 
> I would wait for Robin, he knows this better, but I belive this was
> broadly his point in the original email..

Thanks Jason for context and detailed arguments. Robin did not chime in
yet, but from what I understood the DT-child-node approach will be the
way we should go here.

I accept above point of view and I am fine with this, thus Vishnu and
Vikash - please go ahead with DT-child-node solution we had some time ago.

Best regards,
Krzysztof

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Konrad Dybcio]

On 6/18/26 5:17 PM, Jason Gunthorpe wrote:
> On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote:

[...]

> So, if we are going to do a hack in DT to accomodate Linux, I argue to
> choose explicit child devices so VPU does not need to create a special
> bus, call of_dma_configue, or hack in new DMA API things that only it
> will ever use.

Bit late to the party, but I'll chime in with some more "amazing news"..

All of the multimedia HW on QC platforms (camera, display, GPU, video
and their specialized variations) has at least part of the same problems:

* Multiple SID groups that need to be accommodated for different purposes
  (normal vs secure buffers provided by the same device, different
  "logical functions" generally speaking) apply to all of them

* Different IOVA limitations per SID group seems to also concern at
 least the camera uC ("ICP") (but not all of camera hw)

* Remoteprocs (and therefore also the audio stack) expose a number of
  subfunctions, some of which we currently model as subnodes (although
  many arguably only exist as such because someone decided it was
  convenient to express them this way). This, for example led to the
  representation of each SID group associated with the remoteproc
  (fastrpc/"run compute on rproc") as a separate node:

-- qcom/hamoa.dtsi
remoteproc_adsp: remoteproc@6800000 {
	[...]

	// no iommus OR iommus used for another purpose (fw loading)

	fastrpc {
		// no iommus

		compute-cb@3 {
			compatible = "qcom,fastrpc-compute-cb";
			reg = <3>;
			iommus = <&apps_smmu 0x1003 0x80>,
				 <&apps_smmu 0x1063 0x0>;
			dma-coherent;
		};

		compute-cb@4 {
			compatible = "qcom,fastrpc-compute-cb";
			reg = <4>;
			iommus = <&apps_smmu 0x1004 0x80>,
				 <&apps_smmu 0x1064 0x0>;
			dma-coherent;
		};

		[...] (there's a lot of them)
	};
};

There may be more hiding in plain sight, but those are the ones I'm
aware of.


I was kinda hoping there would be more buy-in to follow what PCIe
does, but to my understanding you're opposed to it because "vpu_bus"
is not dynamically discoverable. PCIe generally obviously is, but
we already have prior art regarding hardwired/onboard devices - many
qcom DTs carry per-board iommu-map overrides to please the allocator
with known-in-advance BDF values (because the HW has only so many
SIDs):

-- qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
iommu-map = <0x0 &apps_smmu 0x1c00 0x1>,
            <0x100 &apps_smmu 0x1c01 0x1>,
            <0x208 &apps_smmu 0x1c04 0x1>,
            <0x210 &apps_smmu 0x1c05 0x1>,
            <0x218 &apps_smmu 0x1c06 0x1>,
            <0x300 &apps_smmu 0x1c07 0x1>,
            <0x400 &apps_smmu 0x1c08 0x1>,
            <0x500 &apps_smmu 0x1c09 0x1>,
            <0x501 &apps_smmu 0x1c10 0x1>;

Although it seems to me that it's more of a hack than anything else..


With that in mind, do you still prefer that this is handled through
separate nodes, presumably for all of the aforementioned cases?

Konrad

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Robin Murphy]

On 17/07/2026 11:44 am, Konrad Dybcio wrote:
> On 6/18/26 5:17 PM, Jason Gunthorpe wrote:
>> On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote:
> 
> [...]
> 
>> So, if we are going to do a hack in DT to accomodate Linux, I argue to
>> choose explicit child devices so VPU does not need to create a special
>> bus, call of_dma_configue, or hack in new DMA API things that only it
>> will ever use.
> 
> Bit late to the party, but I'll chime in with some more "amazing news"..
> 
> All of the multimedia HW on QC platforms (camera, display, GPU, video
> and their specialized variations) has at least part of the same problems:
> 
> * Multiple SID groups that need to be accommodated for different purposes
>    (normal vs secure buffers provided by the same device, different
>    "logical functions" generally speaking) apply to all of them
> 
> * Different IOVA limitations per SID group seems to also concern at
>   least the camera uC ("ICP") (but not all of camera hw)
> 
> * Remoteprocs (and therefore also the audio stack) expose a number of
>    subfunctions, some of which we currently model as subnodes (although
>    many arguably only exist as such because someone decided it was
>    convenient to express them this way). This, for example led to the
>    representation of each SID group associated with the remoteproc
>    (fastrpc/"run compute on rproc") as a separate node:
> 
> -- qcom/hamoa.dtsi
> remoteproc_adsp: remoteproc@6800000 {
> 	[...]
> 
> 	// no iommus OR iommus used for another purpose (fw loading)
> 
> 	fastrpc {
> 		// no iommus
> 
> 		compute-cb@3 {
> 			compatible = "qcom,fastrpc-compute-cb";
> 			reg = <3>;
> 			iommus = <&apps_smmu 0x1003 0x80>,
> 				 <&apps_smmu 0x1063 0x0>;
> 			dma-coherent;
> 		};
> 
> 		compute-cb@4 {
> 			compatible = "qcom,fastrpc-compute-cb";
> 			reg = <4>;
> 			iommus = <&apps_smmu 0x1004 0x80>,
> 				 <&apps_smmu 0x1064 0x0>;
> 			dma-coherent;
> 		};
> 
> 		[...] (there's a lot of them)
> 	};
> };
> 
> There may be more hiding in plain sight, but those are the ones I'm
> aware of.
> 
> 
> I was kinda hoping there would be more buy-in to follow what PCIe
> does, but to my understanding you're opposed to it because "vpu_bus"
> is not dynamically discoverable. PCIe generally obviously is, but
> we already have prior art regarding hardwired/onboard devices - many
> qcom DTs carry per-board iommu-map overrides to please the allocator
> with known-in-advance BDF values (because the HW has only so many
> SIDs):

It's not really about dynamic discoverability, it's more the fact that 
PCI requester IDs are a real and well-defined thing.

> -- qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
> iommu-map = <0x0 &apps_smmu 0x1c00 0x1>,
>              <0x100 &apps_smmu 0x1c01 0x1>,
>              <0x208 &apps_smmu 0x1c04 0x1>,
>              <0x210 &apps_smmu 0x1c05 0x1>,
>              <0x218 &apps_smmu 0x1c06 0x1>,
>              <0x300 &apps_smmu 0x1c07 0x1>,
>              <0x400 &apps_smmu 0x1c08 0x1>,
>              <0x500 &apps_smmu 0x1c09 0x1>,
>              <0x501 &apps_smmu 0x1c10 0x1>;
> 
> Although it seems to me that it's more of a hack than anything else..

No, that is describing a genuine mapping of physical PCIe requester ID 
values to physical SMMU StreamID values which exists in the system, and 
which any OS needs to understand in order to be able to configure the 
SMMU correctly at all. Sure, that mapping probably is programmed in a 
lookup table in the root complex by the bootloader in a board-specific 
manner (like I know the NXP Layerscape platforms do, for instance) but 
it's still a real description of the system configuration, and it's 
perfectly fine if StreamIDs and/or LUT entries are limited to only 
configure BDFs known to be present at boot (if there's no SR-IOV or 
hotplug to worry about), since it's a reasonable expectation that an OS 
won't go arbitrarily renumbering buses just for fun.

It's another thing entirely to have a bunch of distinct logical devices 
whose only physical identifier is already an SMMU StreamID, then invent 
a fake mapping of made-up numbers to StreamIDs in order to pretend they 
can use common infrastructure, except still needing invasive hacks at 
almost every level of said common infrastructure in order to even try to 
make it actually work.

How anyone can read, let alone write "This creates a limitation when 
child requires a different iommu-address range than its parent, as 
device tree cannot express the reservation per child." and not 
immediately conclude that the Devicetree binding must be wrong because 
it is unable to adequately describe the properties and requirements of 
the hardware, frankly I struggle to imagine...

Thanks,
Robin.

> 
> 
> With that in mind, do you still prefer that this is handled through
> separate nodes, presumably for all of the aforementioned cases?
> 
> Konrad

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Jason Gunthorpe]

On Fri, Jul 17, 2026 at 12:44:54PM +0200, Konrad Dybcio wrote:

> I was kinda hoping there would be more buy-in to follow what PCIe
> does, but to my understanding you're opposed to it because "vpu_bus"
> is not dynamically discoverable.

PCIe allows describing devices in DT. What this weird vpu_bus thing
seems to be about is to actively avoid describing the devices in DT
while simultaenously treating them like devices. I think it makes no
sense..

IMHO the approach inverts the thing, you start the main driver then
use vpu_bus to dynamically create a bunch of struct device DMA handles
for the main driver to use.

I think it is much better if you start the main driver, use the new
component stuff:

https://docs.kernel.org/driver-api/component.html

To aggregate a driver from the struct device DMA handles that DT will
create automatically. ie the reversed flow, the struct devices
pre-exist created by DT instead of being created by code in your
driver.

Jason