Re: [PATCH v5 07/14] media: iris: Enable Secure PAS support with IOMMU managed by Linux

[Vishnu Reddy]

On 5/13/2026 7:12 PM, Dmitry Baryshkov wrote:
> On Mon, May 11, 2026 at 01:31:04PM +0530, Mukesh Ojha wrote:
>> On Fri, May 08, 2026 at 11:20:06PM +0300, Dmitry Baryshkov wrote:
>>> On Sat, May 09, 2026 at 12:29:56AM +0530, Vishnu Reddy wrote:
>>>> From: Mukesh Ojha <mukesh.ojha@xxxxxxxxxxxxxxxx>
>>>>
>>>> Most Qualcomm platforms feature a proprietary hypervisor (such as Gunyah
>>>> or QHEE), which typically handles IOMMU configuration. This includes
>>>> mapping memory regions and device memory resources for remote processors
>>>> by intercepting qcom_scm_pas_auth_and_reset() calls. These mappings are
>>> No the calls to those functions are not intercepted. Doesn't hypervisor
>>> simply implement the SCM calls?
>> All the SMC calls are intercepted whenever Gunyah or QHEE hypervisor is present
>> and in most of the case the preparational work for the TZ like in case of
>> qcom_scm_pas_auth_and_reset() it does create/register SHMbridge over PIL memory
>> so that the TZ can access the memory and then calls same SMC call to TZ for
>> authentication and once done it comes back does mapping the PIL region
>> and call bring up sequence of the co-processor.
> I see, thanks for the explanation.
>
>>     SMC  SHM setup    SMC (auth)        map memory/resource and trigger reset sequence
>> HLOS ==> Gunyah(QHEE)   ==> TZ    ==>    Gunyah(QHEE)        === ==>      IRIS 
>>
>>
>>>> later removed during teardown. Additionally, SHM bridge setup is required
>>>> to enable memory protection for both remoteproc metadata and its memory
>>>> regions.
>>>>
>>>> When the hypervisor is absent, the operating system must perform these
>>>> configurations instead.
>>>>
>>>> Support for handling IOMMU and SHM setup in the absence of a hypervisor
>>>> is now in place. Extend the Iris driver to enable this functionality on
>>>> platforms where IOMMU is managed by Linux (i.e., non-Gunyah, non-QHEE).
>>> I fail to identify, which changes correspond to this description. If
>>> it's about the PAS context creation, could you please be more specific?
>> I think, commit text is trying to tell the Infra to support any Secure PIL when IOMMU is
>> managed by Linux at EL2 and the dependency related to SHM set up in Linux are done as
>> part of [1] are in upstream.
> Ok... I'd say, this part of the commit message might need some
> polishing, but I can't give an exact advice here.
>
>> [1]
>> https://lore.kernel.org/lkml/20260105-kvmrprocv10-v10-0-022e96815380@xxxxxxxxxxxxxxxx/
>>
>>>> Additionally, the Iris driver must map the firmware and its required
>>>> resources to the firmware SID, which is now specified via iommu-map in
>>>> the device tree.
>>> Why? You miss the most important part here.
>> Sorry, I did not get.. are you looking for explaination here, why via iommu-map in
>> commit text ?
> Yes. Why are you using iommu-map instead of listing it in the main
> iommus entry?

Without hypervisor: iommu-map is populated, so the driver creates a firmware
device and handles the IOMMU mapping.

With Gunyah/QHEE: iommu-map is omitted, firmware device is NULL, and the driver
skips mapping since the hypervisor takes care of it.

The main iommus entry already holds other stream IDs (pixel, non-pixel, etc.)
and cannot be used to distinguish the firmware SID or infer hypervisor presence,
hence the use of a separate iommu-map property.

>>>> Reviewed-by: Vishnu Reddy <busanna.reddy@xxxxxxxxxxxxxxxx>
>>>> Co-developed-by: Vikash Garodia <vikash.garodia@xxxxxxxxxxxxxxxx>
>>>> Signed-off-by: Vikash Garodia <vikash.garodia@xxxxxxxxxxxxxxxx>
>>>> Signed-off-by: Mukesh Ojha <mukesh.ojha@xxxxxxxxxxxxxxxx>
>>>> Signed-off-by: Vishnu Reddy <busanna.reddy@xxxxxxxxxxxxxxxx>
>>>> ---
>>>>  drivers/media/platform/qcom/iris/iris_core.h     |  4 ++
>>>>  drivers/media/platform/qcom/iris/iris_firmware.c | 72 ++++++++++++++++++++----
>>>>  2 files changed, 66 insertions(+), 10 deletions(-)
>>>>
>>> -- 
>>> With best wishes
>>> Dmitry
>> -- 
>> -Mukesh Ojha