Re: [PATCH 2/2] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
From: Bryan O'Donoghue
Date: Tue Jun 09 2026 - 09:13:58 EST
On 04/06/2026 07:38, Vikash Garodia wrote:
The problem here is in the reponse to the email you linked:
On 6/2/2026 9:05 PM, Daniel J Blueman wrote:
On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@xxxxxxxxxx> wrote:
On 01/06/2026 05:13, Daniel J Blueman wrote:
On X1-family hamoa platforms, Iris DMA below IOVA 0x25800000 (600MB)
triggers unhandled SMMU page faults
How do we know that is a correct address - does it come from qcom
documentation or trial and error ?
@Vikash, beyond your comment I linked in the patch [1] kindly cite a
source for the different stream-ID <600MB behaviour, and share
specifics, eg if silicon, firmware, or driver and constraint, defect
or otherwise, so I can include a definitive description.
Also good to know if my workaround is good for long-term, or on the
other hand handling streams <600MB is important/useful.
Thanks Daniel for raising this patch. Did you also try the memory fix i
mentioned in the bug [1] discussion ?
Coming to 600MB, this have been the VPU hardware restriction all the
while since venus days, and since address could not go deeper all the
way lower than 600MB, the issue never popped up earlier.
Consider the memory layout split as below (Iris device range is capped
to 0xe0000000)
|-----600MB-----|-----(0xe0000000 - 600MB)-----|----IO reg--|
0-600MB range, VPU hardware would reserve this to generate different
stream-IDs primarily for internal (non-pixel) buffers.
0-600 --> VPU would generate *secure* stream ID for non-pixel buffers
601 - 0xe0000000 --> VPU would generate non-secure stream ID for
non-pixel buffers.
When many concurrent sessions were tried, non-pixel buffers were mapped
into 0-600MB range, and VPU generated secure ID for those. Since those
were not associated with the iommus configured for iris node, it led to
USF (un-identified stream fault) and device would crash.
Keeping the region reserved, makes the non-pixel buffer always in the
non secure range (601-..) and avoids the crash.
Downside of this design - It would eventually reserve 0-600MB un-map
'able for all buffer types, like pixel as well which do not have any
such restriction.
Forward looking design - create devices dynamically and set reserve
regions for those specific device using the api [1], instead of applying
one reserve for all.
[1]
https://lore.kernel.org/all/20260119054936.3350128-1-busanna.reddy@xxxxxxxxxxxxxxxx/
https://lore.kernel.org/all/cfd23f75-8952-4463-abd5-815b995031b0@xxxxxxx/
- Inheriting the parent's properties is wrong
- We should just have a bus
But that leads us to churning DT and we'd have to figure out how/why to do it purely for the purpose of differentiating SIDs within Iris. There is no separate hardware - its one VPU which needs to figure out its IOVA for different SIDs.
Krzysztof would rightly say no - again - to putting collateral into DT to differentiate pixel streams based on SID, because that's not a hardware property.
- You have pixel and non-pixel SIDs that have to hit Linux
- You have to keep non-pixel allocations >= 600 MB
- You can allow pixel < 600mb =>
Daniel's patch is too restrictive
But what we can do is add information to the iris platform descriptors to enumerate what are the valid IOVA ranges for pixel and non-pixel data and then change the allocation code to operate from those platform-code described IOVAs.
No new iommu properties, not arguing about plonking SID/pixel-path data into DT.
Just teach the driver what the valid ranges are and allocate IOVAs based on those ranges.
I think Daniel's patch should be taken as it fixes a real bug for users right now but, I equally think its a NAK for any new SoC.
This IOVA allocation needs to be tackled correctly and IMO that needs to be and should be done via platform descriptors for valid ranges of IOVA.
No mad stuff about SIDs in DT, no lengthy arguments about adding strange iommu properties.
---
bod