On 11/24/25 7:45 AM, Mukesh Ojha wrote: > 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.
Hamoa's little brother should have ath12k_ahb.. and I assume IPA is present on at least some platforms where there's a modem (QCM6490?) Konrad
