On 9/22/25 12:33 PM, Mukesh Ojha wrote: > On Mon, Sep 22, 2025 at 11:53:34AM +0200, Stephan Gerhold wrote: >> On Mon, Sep 22, 2025 at 03:17:32PM +0530, Mukesh Ojha wrote: >>> On Mon, Sep 22, 2025 at 10:10:42AM +0200, Stephan Gerhold wrote: >>>> On Sun, Sep 21, 2025 at 01:10:58AM +0530, Mukesh Ojha wrote: >>>>> A few months ago, we discussed the challenges at Linaro Connect 2025 [1] >>>>> related to Secure PAS remoteproc enablement when Linux is running at EL2. >>>>> >>>>> [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. >>>>> >>>>> This series has dependency on below series for creating SHMbridge over >>>>> carveout memory. It seems to be merged on linux-next and pushed for 6.18. >>>>> >>>>> https://lore.kernel.org/lkml/20250911-qcom-tee-using-tee-ss-without-mem-obj-v12-0-17f07a942...@oss.qualcomm.com/ >>>>> >>>>> It is based on next-20250919 where above series is already merged >>>>> 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. >>>>> >>>> >>>> When testing your series on Lemans, what happens with the additional >>>> SIDs from the peripherals assigned to the remoteproc ("DMA masters" in >>>> your talk)? Are these running in bypass because the previous firmware >>>> component (Gunyah?) had allocated SMMU SMRs for these? >>> >>> There is no DMA usecase present for Lemans but can exist for other SoC. >>> >>>> >>>> It would be worth mentioning this in the cover letter (and perhaps as >>>> part of the EL2 overlay patch as well), since it is unclear otherwise >>>> why your series does not result in crashes the first time a remoteproc >>>> tries to use one of these DMA-capable peripherals. >>> >>> As I said above, It is not present for Lemans; >>> >> >> Ok, thanks for clarifying. In other words: The IOMMU SIDs you have >> specified in the overlay so far are sufficient for the current firmware >> use cases to run successfully on Lemans? > > Yes. > >> >>> To handle the DMA use case in generic way, we might require extention >>> change in remoteproc or generic iommu framework to handles these >>> scenario like its SID and memory resources should be communicated >>> through firmware resource table or device tree or some way. >>> >>> And same scenario when resource table section not present in firmware >>> binary ? like most of the Qualcomm platforms, how these cases would be >>> handled and I believe this is similar to the problem video is facing for >>> non-pixel case. >> >> It is sort of similar, except in this case Linux doesn't really do >> anything itself with the mappings. In the video case, Linux dynamically >> maps buffers (or similar) into those address spaces, while in the >> remoteproc case those are fixed(?) for a specific firmware binary. At >> least if I understood the explanations in your talk correctly. > > Memory region used by DMA use case would be fixed with subsystem > carveout memory but need to be mapped with DMA SID before subsystem > boots up so that it could use the DMA. So, it looks to be subdevice > for remote processor but programming of DMA taken care by > remote processor firmware and those detail would not be mentioned in > Application processor device tree.
Sounds like something we can just stick into the resource table too, then, along with all the SID data if/once that proposal gets through Konrad
