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/[email protected]/ > >>> - 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/[email protected]/ > > > > [2] > > https://lore.kernel.org/lkml/[email protected]/ > > 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
