Message-ID: <20251124064558.aaartbglgvcj7w5r@hu-mojha-hyd.qualcomm.com>
Date: Mon, 24 Nov 2025 12:15:58 +0530
From: Mukesh Ojha <mukesh.ojha@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 00/14] Peripheral Image Loader support for Qualcomm
 SoCs running Linux host at EL2

On Fri, Nov 21, 2025 at 04:08:36PM +0100, Konrad Dybcio wrote:
> On 11/21/25 12:37 PM, Mukesh Ojha wrote:
> > On Fri, Nov 21, 2025 at 11:27:57AM +0000, Bryan O'Donoghue wrote:
> >> On 21/11/2025 11:01, Mukesh Ojha wrote:
> >>> In May 2025, we discussed the challenges at Linaro Connect 2025 [1]
> >>> related to Secure PAS remoteproc enablement when Linux is running at EL2
> >>> for Qualcomm SoCs.
> >>>
> >>> [1] https://resources.linaro.org/en/resource/sF8jXifdb9V1mUefdbfafa
> >>>
> >>> Below, is the summary of the discussion.
> >>>
> >>> Qualcomm is working to enable remote processors on the SA8775p SoC with
> >>> a Linux host running at EL2. In doing so, it has encountered several
> >>> challenges related to how the remoteproc framework is handled when Linux
> >>> runs at EL1.
> >>>
> >>> One of the main challenges arises from differences in how IOMMU
> >>> translation is currently managed on SoCs running the Qualcomm EL2
> >>> hypervisor (QHEE), where IOMMU translation for any device is entirely
> >>> owned by the hypervisor. Additionally, the firmware for remote
> >>> processors does not contain a resource table, which would typically
> >>> include the necessary IOMMU configuration settings.
> >>>
> >>> Qualcomm SoCs running with QHEE (EL2) have been utilizing the Peripheral
> >>> Authentication Service (PAS) from TrustZone (TZ) firmware to securely
> >>> authenticate and reset remote processors via a single SMC call,
> >>> _auth_and_reset_. This call is first trapped by QHEE, which then invokes
> >>> TZ for authentication. Once authentication is complete, the call returns
> >>> to QHEE, which sets up the IOMMU translation scheme for the remote
> >>> processors and subsequently brings them out of reset. The design of the
> >>> Qualcomm EL2 hypervisor dictates that the Linux host OS running at EL1
> >>> is not permitted to configure IOMMU translation for remote processors,
> >>> and only a single-stage translation is configured.
> >>>
> >>> To make the remote processor bring-up (PAS) sequence
> >>> hypervisor-independent, the auth_and_reset SMC call is now handled
> >>> entirely by TZ. However, the issue of IOMMU configuration remains
> >>> unresolved, for example a scenario, when KVM host at EL2 has no
> >>> knowledge of the remote processors’ IOMMU settings.  This is being
> >>> addressed by overlaying the IOMMU properties when the SoC runs a Linux
> >>> host at EL2. SMC call is being provided from the TrustZone firmware to
> >>> retrieve the resource table for a given subsystem.
> >>>
> >>> There are also remote processors such as those for video, camera, and
> >>> graphics that do not use the remoteproc framework to manage their
> >>> lifecycle. Instead, they rely on the Qualcomm PAS service to
> >>> authenticate their firmware. These processors also need to be brought
> >>> out of reset when Linux is running at EL2. The client drivers for these
> >>> processors use the MDT loader function to load and authenticate
> >>> firmware. Similar to the Qualcomm remoteproc PAS driver, they also need
> >>> to retrieve the resource table, create a shared memory bridge
> >>> (shmbridge), and map the resources before bringing the processors out of
> >>> reset.
> >>>
> >>> It is based on next-20251120 and tested on SA8775p which is now called
> >>> Lemans IOT platform and does not addresses DMA problem discussed at
> >>> [1] which is future scope of the series.
> >>>
> >>> Changes in v8: https://lore.kernel.org/lkml/20251113-kvm-rproc-v7-v7-0-df4910b7c20a@oss.qualcomm.com/
> >>>   - Addressed suggestion from Stephen which was regarding commit message(9/14),
> >>>     debug log(12/14) suggestion, and return type change(4/14).
> >>>   - Added R-b tag on 10/14 .
> >> Sorry.
> >>
> >> Did we actually come up with a cogent reason to omit the video firmware
> >> loading here ?
> >>
> >> AFAIU it is required for Lemans and Glymur - leaving it out is blocking
> >> getting video stuff done and storing up trouble.
> >>
> >> What exactly is the blockage - is it something you want help with ?
> > 
> > I replied to you here[1] and given my reason..till something concluded on
> > "multi-cell IOMMU[2]", I can not add video and block what is working
> > already.
> > 
> > [1]
> > https://lore.kernel.org/lkml/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-hyd.qualcomm.com/
> > 
> > [2]
> > https://lore.kernel.org/lkml/cover.1762235099.git.charan.kalla@oss.qualcomm.com/
> 
> I see that the following files call qcom_scm_pas_auth_.*():
> 
> drivers/firmware/qcom/qcom_scm.c
> drivers/gpu/drm/msm/adreno/adreno_gpu.c
> drivers/media/platform/qcom/iris/iris_firmware.c
> drivers/media/platform/qcom/venus/firmware.c
> drivers/net/ipa/ipa_main.c
> drivers/net/wireless/ath/ath12k/ahb.c
> drivers/remoteproc/qcom_q6v5_pas.c
> drivers/remoteproc/qcom_wcnss.c
> 
> iris is difficult, rproc is done, adreno doesn't need it..
> 
> would ath12k_ahb or IPA be affected by this series as well?

Yes, they would be affected, and the modem as well, when Linux is
running at EL2. However, I do not see them present in any of the QLi and
targeted compute SoCs at the moment. Therefore, our firmware does not
support it yet.

> 
> Konrad

-- 
-Mukesh Ojha

Powered by blists - more mailing lists