Mukesh Kumar Ojha

| Kite - Bootstrap Admin Template

Speaker

Staff engineer at Qualcomm
Qualcomm
Joined February 2025

LIS25-141 QCOM secure remoteproc solution for Linux host at EL2"

Panel discussion - 40 minutes

Virtualization

Wednesday, 14 May 16:30 - 17:05 (Europe/Lisbon)
Your timezone: Wednesday, 14 May 16:30 - 17:05 (Europe/Lisbon)
Keynote room | Floriana II

Qualcomm aims to enable remote processors on the SA8775p SoC running Linux at EL2 (e.g., KVM). To support this configuration, the existing Qualcomm remoteproc PAS driver needs revision. The primary challenge lies in the differences in IOMMU translation handling between SoCs running the Qualcomm EL2 hypervisor (QHEE) and those running Linux at EL2 (e.g., KVM). Several issues need to be addressed: 1. IOMMU Translation Ownership: Currently, QHEE fully controls IOMMU translation for the remoteproc device. 2. Resource Table Absence: Qualcomm remote processors' firmware lacks a resource table for IOMMU configuration settings, which the Linux remoteproc core expects. Some SoC vendors provide this information in a dedicated DDR region via boot firmware. 3. Peripheral Authentication Service (PAS): Qualcomm SoCs with QHEE (EL2) use PAS from TrustZone (TZ) firmware to securely authenticate and reset remote processors via a single SMC call, auth_and_reset. This call is trapped to QHEE, which then calls TZ for authentication. After authentication, QHEE sets up the IOMMU translation scheme and brings the processors out of reset. The Qualcomm EL2 hypervisor design prevents the Linux host OS running at EL1 from setting up IOMMU translation for remote processors, allowing only a single stage configuration. To make the PAS sequence hypervisor-independent, the auth_and_reset SMC call is now entirely handled by TZ. However, the Linux host running at EL2 still lacks knowledge of the remote processors' resource table to perform IOMMU translation. 4. DMA Device Handling: Existing Qualcomm remote processors handle a use case where a DMA device assigned to it has its own SID (Stream ID) different from the remoteproc one. At reset, QHEE running at EL2 detects the DMA memory region within the remoteproc carveout memory and maps it with the DMA SID. When Linux runs at EL2, DMA region information and its mapping need to be managed by Linux. One approach we explored involves including resources like IOMMUs for remoteproc carveout and qcom,devmem-specific bindings for device memory in the SoC remoteproc device tree node. These properties are optional and will only be overlaid by the firmware if it runs with a non-QHEE based hypervisor like KVM. We have submitted an initial series[1] supporting this approach, but the community did not favor keeping the resource table in the device tree. To solve the first three problems, we are now pursuing the path to obtain the resource table from TrustZone, and our remoteproc PAS driver will now map the carveout and devmem resources for remoteproc. We have also sought feedback on the DMA device handling issue (point 4) to see if similar use cases are already supported or discussed[2]. We explored one way where we can assume DMA as a remoteproc subdevice with its own SID and memory region associated as identity mapping. In the presentation, we will discuss how Qualcomm is looking to solve this problem and seek valuable feedback from kernel experts. [1] https://lore.kernel.org/lkml/20241004212359.2263502-1-quic_mojha@quicinc.com/ [2] https://lore.kernel.org/lkml/CAN3W6UVqqY1P+0ZV3nwY-vmT3fArGhoF959H_15K3iz1z7shSw@mail.gmail.com/

About

Mukesh is a Linux Kernel BSP Engineer at Qualcomm, where he plays a pivotal role in developing and supporting the Linux kernel for Qualcomm Snapdragon chipsets. At Qualcomm, Mukesh collaborates closely with cross-functional teams, including hardware, architecture, and test engineers, to ensure seamless kernel deliverables from the presilicon to post-silicon phases of the SoC. He helps with fixing stability issues in both downstream and upstream drivers and optimizing the performance of the Linux kernel. He has been involved in upstreaming downstream fixes and features like Minidump and has contributed to resolving multiple core kernel issues across various subsystems. His expertise in debugging using tools like T32 and gdb, along with his proficiency in tracing and performance analysis, allows him to identify and resolve kernel bottlenecks efficiently.