[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251105081421.f6j7ks5bd4dfgr67@hu-mojha-hyd.qualcomm.com>
Date: Wed, 5 Nov 2025 13:44:21 +0530
From: Mukesh Ojha <mukesh.ojha@....qualcomm.com>
To: Bryan O'Donoghue <bod@...nel.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 v6 00/14] Peripheral Image Loader support for Qualcomm
SoCs running Linux host at EL2
On Tue, Nov 04, 2025 at 04:25:26PM +0000, Bryan O'Donoghue wrote:
> On 04/11/2025 07:35, 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-20251103 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 v6: https://lore.kernel.org/lkml/20251013-kvm_rprocv5-v5-0-d609ed766061@oss.qualcomm.com/
> > - Added comments made by Bryan to save some cycles and added in 2/14
> > which could change patch order.
> > - Renamed qcom_scm_pas_context_init to devm_qcom_scm_pas_context_init()
> > - Replaced devm_kzalloc with kzalloc for output_rt in scm function as
> > remoteproc framework does not usage devm_ api for resource table
> > pointer which is cause mem-abort issue start/stop test.
> > - Removed union usage and redundant code from qcom_scm_pas_prep_and_init_image().
> >
> > Changes in v5: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-0-de841623af3c@oss.qualcomm.com/
> > - Replaced minitems with maxitems.
> > - Addressed comments made by Bryan, Mani and Konrad.
> > - Fixed some of highlighted issues in v4.
> > - Added a new patch which removes qcom_mdt_pas_init() from exported
> > symbol list.
> > - Slight change in v4's 5/12, so that it does use qcom_mdt_pas_load()
> > directly while it should use in the commit where it gets introduced.
> > Hence, reordered the patches a bit like v4 5/12 comes early before
> > 4/12.
> >
> > Changes in v4: https://lore.kernel.org/lkml/20250921-kvm_rproc_pas-v3-0-458f09647920@oss.qualcomm.com/
> > - Fixed kernel robot warning/errors.
> > - Reworded some of the commit log, code comment as per suggestion from Bryan.
> > - Added support of gpdsp0 and gpdsp1 and disabled iris node.
> > - Add R-b tag to some of the reviewed patches.
> > - Rename struct qcom_scm_pas_cxt to qcom_scm_pas_context.
> >
> > Changes in v3: https://lore.kernel.org/lkml/20250819165447.4149674-1-mukesh.ojha@oss.qualcomm.com/
> > - Dropped video subsystem enablement for now, could add it in future
> > or on a separate series.
>
> I specifically think it is the wrong thing to do, to drop video enablement
> from this series.
There is no dependency of this series on video enablement. The only
reason I included it in my initial series was that video or other
non-remoteproc subsystems would need to call the resource table SMC call
and map the resources. Since I have dropped video support have dropped
the the helper function too that parses and maps the resources in this
newer series, it is no longer required.
https://lore.kernel.org/lkml/20250819165447.4149674-9-mukesh.ojha@oss.qualcomm.com/
>
> Its just papering over the cracks. The right thing to do is to have the
> technical disucssion and agree a way forward, not to drop things that feel
> too contentious.
>
> What's really so contentious about
>
> video-firmware {
> iommu data here
> };
>
> As has been done with ChromeOS on venus thus far ?
>
> All that has to be made is a case for it.
Since there was an objection to removing the Venus YAML from the Iris
YAML [1], we cannot use it. We had a few similar use cases as mentioned
here [2], and you were part of all the discussions and agreed to remove
the item that could take time [3]. Therefore, it seemed valid to drop it
for now. A new approach[4] for video to handle these kind of sceanario
has been posted.
[1]
https://lore.kernel.org/lkml/20250823155349.22344-2-krzysztof.kozlowski@linaro.org/
[2]
https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/T/#m9891945187671417f25f134097383b72aa7f47c2
[3]
https://lore.kernel.org/lkml/ad5a58a6-2545-4429-9388-e8ad84319570@linaro.org/
[4]
https://lore.kernel.org/lkml/cover.1762235099.git.charan.kalla@oss.qualcomm.com/
>
> > - Addressed most of the suggestion from Stephen and Bryan like some
> > remoteproc code checking resource table presence or right error
> > code propagation above the layer.
> > - Added leman-el2 overlay file.
> > - Added missed iommus binding which was missed last series.
> > - Separated qcom_mdt_pas_load() patch and its usage.
> > - Patch numbering got changed compared to last version
> >
> > Changes in v2: https://lore.kernel.org/lkml/20241004212359.2263502-1-quic_mojha@quicinc.com/
> > - A lot has changed from the V1 and a fresh look would be preferred.
> > - Removed approach where device tree contain devmem resources in
> > remoteproc node.
> > - SHMbridge need to created for both carveout and metadata memory
> > shared to TZ in a new way.
> > - Now, resource table would be given by SMC call which need to mapped
> > along with carveout before triggering _auth_and_reset_.
> > - IOMMU properties need to be added to firmware devices tree node when Linux
> > control IOMMU.
> >
> > ---
> > Mukesh Ojha (14):
> > dt-bindings: remoteproc: qcom,pas: Add iommus property
> > firmware: qcom_scm: Remove redundant piece of code
> > firmware: qcom_scm: Rename peripheral as pas_id
> > firmware: qcom_scm: Introduce PAS context initialization helper function
> > remoteproc: pas: Replace metadata context with PAS context structure
> > soc: qcom: mdtloader: Add PAS context aware qcom_mdt_pas_load() function
> > soc: qcom: mdtloader: Remove qcom_mdt_pas_init() from exported symbols
> > firmware: qcom_scm: Add a prep version of auth_and_reset function
> > firmware: qcom_scm: Simplify qcom_scm_pas_init_image()
> > firmware: qcom_scm: Add SHM bridge handling for PAS when running without QHEE
> > firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table
> > remoteproc: pas: Extend parse_fw callback to fetch resources via SMC call
> > remoteproc: qcom: pas: Enable Secure PAS support with IOMMU managed by Linux
> > arm64: dts: qcom: Add EL2 overlay for Lemans
> >
> > .../bindings/remoteproc/qcom,pas-common.yaml | 3 +
> > arch/arm64/boot/dts/qcom/Makefile | 10 +
> > arch/arm64/boot/dts/qcom/lemans-el2.dtso | 41 +++
> > drivers/firmware/qcom/qcom_scm.c | 387 ++++++++++++++++++---
> > drivers/firmware/qcom/qcom_scm.h | 1 +
> > drivers/remoteproc/qcom_q6v5_pas.c | 166 +++++++--
> > drivers/soc/qcom/mdt_loader.c | 43 ++-
> > include/linux/firmware/qcom/qcom_scm.h | 30 +-
> > include/linux/soc/qcom/mdt_loader.h | 22 +-
> > 9 files changed, 593 insertions(+), 110 deletions(-)
> > ---
> > base-commit: 9823120909776bbca58a3c55ef1f27d49283c1f3
> > change-id: 20251104-kvm_rproc_v6-6329e4d594fe
> >
> > Best regards,
> > --
> > -Mukesh Ojha
> >
> >
>
--
-Mukesh Ojha
Powered by blists - more mailing lists