Message-ID: <2a5f3286-7f79-4003-afcb-082dc61b6d2d@oss.qualcomm.com>
Date: Wed, 8 Oct 2025 11:49:51 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Mukesh Ojha <mukesh.ojha@....qualcomm.com>,
        Stephan Gerhold <stephan.gerhold@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, linux-arm-msm@...r.kernel.org,
        linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Subject: Re: [PATCH v3 00/12] Peripheral Image Loader support for Qualcomm
 SoCs running Linux host at EL2

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-17f07a942b8d@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

Powered by blists - more mailing lists