* Re: [PATCH 2/2] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
2026-06-04 6:38 ` Vikash Garodia
@ 2026-06-08 3:48 ` Val Packett
2026-06-08 4:17 ` Xilin Wu
2026-06-08 13:36 ` Bryan O'Donoghue
2026-06-09 13:01 ` Bryan O'Donoghue
2026-06-10 1:14 ` Daniel J Blueman
2 siblings, 2 replies; 16+ messages in thread
From: Val Packett @ 2026-06-08 3:48 UTC (permalink / raw)
To: Vikash Garodia, Daniel J Blueman, Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bjorn Andersson, Konrad Dybcio,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-media, devicetree,
linux-kernel, stable, Bryan O'Donoghue, Xilin Wu
On 6/4/26 3:38 AM, Vikash Garodia wrote:
>
>
> On 6/2/2026 9:05 PM, Daniel J Blueman wrote:
>> On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@kernel.org> 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.
Umm.. is anything *actually* preventing us from adding the "secure" SID
to the iommu node?
I just saw a patch for sc8280xp that did just add an "extra" SID for iris:
https://github.com/strongtz/linux-radxa-qcom/commit/e92850f792498c3a72d72d667503a29bf6bb0a31
and I'm wondering if that's about the same exact issue.. (Adding sophon@
to Cc: here)
> 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@oss.qualcomm.com/
~val
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
2026-06-08 3:48 ` Val Packett
@ 2026-06-08 4:17 ` Xilin Wu
2026-06-08 13:36 ` Bryan O'Donoghue
1 sibling, 0 replies; 16+ messages in thread
From: Xilin Wu @ 2026-06-08 4:17 UTC (permalink / raw)
To: Val Packett, Vikash Garodia, Daniel J Blueman, Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bjorn Andersson, Konrad Dybcio,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-media, devicetree,
linux-kernel, stable, Bryan O'Donoghue
On 6/8/2026 11:48 AM, Val Packett wrote:
>
> On 6/4/26 3:38 AM, Vikash Garodia wrote:
>>
>>
>> On 6/2/2026 9:05 PM, Daniel J Blueman wrote:
>>> On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@kernel.org> 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.
>
> Umm.. is anything *actually* preventing us from adding the "secure" SID
> to the iommu node?
>
> I just saw a patch for sc8280xp that did just add an "extra" SID for iris:
>
> https://github.com/strongtz/linux-radxa-qcom/commit/
> e92850f792498c3a72d72d667503a29bf6bb0a31
>
> and I'm wondering if that's about the same exact issue.. (Adding sophon@
> to Cc: here)
>
I'm not sure if we're having the same issue. Without adding that SID on
sc8280xp (HFI Gen2 FW), it fails to decode anything and crashes
instantly. From the trustzone log inside the crashdump, I can see that
the buffer isn't actually in the 0-600MB range.
--
Best regards,
Xilin Wu <sophon@radxa.com>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
2026-06-08 3:48 ` Val Packett
2026-06-08 4:17 ` Xilin Wu
@ 2026-06-08 13:36 ` Bryan O'Donoghue
1 sibling, 0 replies; 16+ messages in thread
From: Bryan O'Donoghue @ 2026-06-08 13:36 UTC (permalink / raw)
To: Val Packett, Vikash Garodia, Daniel J Blueman, Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bjorn Andersson, Konrad Dybcio,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-media, devicetree,
linux-kernel, stable, Xilin Wu
On 08/06/2026 04:48, Val Packett wrote:
>
> On 6/4/26 3:38 AM, Vikash Garodia wrote:
>>
>>
>> On 6/2/2026 9:05 PM, Daniel J Blueman wrote:
>>> On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@kernel.org> 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.
>
> Umm.. is anything *actually* preventing us from adding the "secure" SID
> to the iommu node?
Yes.
If the firmware has already provisioned SMMU entries for TZ SIDs then we
would be adding duplicates from Linux, if not then we are claiming TZ
SIDs which we can't actually access if we use them => those entries
would need to be given out to a TZ driver/application of some sort which
we don't have/support now/yet.
> I just saw a patch for sc8280xp that did just add an "extra" SID for iris:
>
> https://github.com/strongtz/linux-radxa-qcom/commit/e92850f792498c3a72d72d667503a29bf6bb0a31
>
> and I'm wondering if that's about the same exact issue.. (Adding sophon@
> to Cc: here)
>
>> 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@oss.qualcomm.com/
>
>
>
> ~val
>
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
2026-06-04 6:38 ` Vikash Garodia
2026-06-08 3:48 ` Val Packett
@ 2026-06-09 13:01 ` Bryan O'Donoghue
2026-07-10 10:51 ` Bryan O'Donoghue
2026-06-10 1:14 ` Daniel J Blueman
2 siblings, 1 reply; 16+ messages in thread
From: Bryan O'Donoghue @ 2026-06-09 13:01 UTC (permalink / raw)
To: Vikash Garodia, Daniel J Blueman, Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bjorn Andersson, Konrad Dybcio,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-media, devicetree,
linux-kernel, stable
On 04/06/2026 07:38, Vikash Garodia wrote:
>
>
> On 6/2/2026 9:05 PM, Daniel J Blueman wrote:
>> On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@kernel.org> 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@oss.qualcomm.com/
The problem here is in the reponse to the email you linked:
https://lore.kernel.org/all/cfd23f75-8952-4463-abd5-815b995031b0@arm.com/
- 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
2026-06-09 13:01 ` Bryan O'Donoghue
@ 2026-07-10 10:51 ` Bryan O'Donoghue
0 siblings, 0 replies; 16+ messages in thread
From: Bryan O'Donoghue @ 2026-07-10 10:51 UTC (permalink / raw)
To: Vikash Garodia, Daniel J Blueman, Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bjorn Andersson, Konrad Dybcio,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-media, devicetree,
linux-kernel, stable
On 09/06/2026 14:01, Bryan O'Donoghue wrote:
> On 04/06/2026 07:38, Vikash Garodia wrote:
>>
>>
>> On 6/2/2026 9:05 PM, Daniel J Blueman wrote:
>>> On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@kernel.org> 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@oss.qualcomm.com/
> The problem here is in the reponse to the email you linked:
>
> https://lore.kernel.org/all/cfd23f75-8952-4463-abd5-815b995031b0@arm.com/
>
> - 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
Please pause merging this patch until this thread bottoms out
https://lore.kernel.org/all/20260709-vpu_iommu_iova_handling-v1-7-72bb62cb2dfd@oss.qualcomm.com
---
bod
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/2] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
2026-06-04 6:38 ` Vikash Garodia
2026-06-08 3:48 ` Val Packett
2026-06-09 13:01 ` Bryan O'Donoghue
@ 2026-06-10 1:14 ` Daniel J Blueman
2 siblings, 0 replies; 16+ messages in thread
From: Daniel J Blueman @ 2026-06-10 1:14 UTC (permalink / raw)
To: Vikash Garodia
Cc: Dikshita Agarwal, Abhinav Kumar, Bjorn Andersson, Konrad Dybcio,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-media, devicetree,
linux-kernel, stable, Bryan O'Donoghue
On Thu, 4 Jun 2026 at 14:39, Vikash Garodia
<vikash.garodia@oss.qualcomm.com> wrote:
> On 6/2/2026 9:05 PM, Daniel J Blueman wrote:
> > On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@kernel.org> 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 ?
With this patch, my Lenovo Slim 7x spontaneously rebooted after
opening 3 tabs of https://ui.com rather than 1 without it. No
crash/reboot is reproducible with the patch I proposed.
> 0-600MB range, VPU hardware would reserve this to generate different
> stream-IDs primarily for internal (non-pixel) buffers.
Thanks for the clearer description; I'll respin my patch with this and
the DT fixes shortly to get the X1 user experience under control until
a real fix.
@all I appreciate the ideas and discussion already ensured!
Dan
--
Daniel J Blueman
^ permalink raw reply [flat|nested] 16+ messages in thread