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? Konrad
