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

[Bryan O'Donoghue <bod@kernel.org>]

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