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

[Robin Murphy <robin.murphy@arm.com>]

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