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]/ > > --- > bod -- -Mukesh Ojha
