linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Manivannan Sadhasivam <mani@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Subject: Re: [PATCH v8 00/14] Peripheral Image Loader support for Qualcomm SoCs running Linux host at EL2
Date: Fri, 21 Nov 2025 11:27:57 +0000	[thread overview]
Message-ID: <0156c327-b867-481e-af24-679f037bfa56@linaro.org> (raw)
In-Reply-To: <20251121-kvm_rproc_v8-v8-0-8e8e9fb0eca0@oss.qualcomm.com>

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/20251113-kvm-rproc-v7-v7-0-df4910b7c20a@oss.qualcomm.com/
>   - 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 ?

---
bod

  parent reply	other threads:[~2025-11-21 11:28 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21 11:01 [PATCH v8 00/14] Peripheral Image Loader support for Qualcomm SoCs running Linux host at EL2 Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 01/14] dt-bindings: remoteproc: qcom,pas: Add iommus property Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 02/14] firmware: qcom_scm: Remove redundant piece of code Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 03/14] firmware: qcom_scm: Rename peripheral as pas_id Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 04/14] firmware: qcom_scm: Introduce PAS context initialization helper function Mukesh Ojha
2025-12-05 22:45   ` Bjorn Andersson
2025-11-21 11:01 ` [PATCH v8 05/14] remoteproc: pas: Replace metadata context with PAS context structure Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 06/14] soc: qcom: mdtloader: Add PAS context aware qcom_mdt_pas_load() function Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 07/14] soc: qcom: mdtloader: Remove qcom_mdt_pas_init() from exported symbols Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 08/14] firmware: qcom_scm: Add a prep version of auth_and_reset function Mukesh Ojha
2025-12-05 22:50   ` Bjorn Andersson
2025-11-21 11:01 ` [PATCH v8 09/14] firmware: qcom_scm: Refactor qcom_scm_pas_init_image() Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 10/14] firmware: qcom_scm: Add SHM bridge handling for PAS when running without QHEE Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 11/14] firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table Mukesh Ojha
2025-11-24 11:48   ` Konrad Dybcio
2025-11-24 15:25     ` Mukesh Ojha
2025-12-03 12:36       ` Konrad Dybcio
2025-12-04 12:28         ` Mukesh Ojha
2025-12-05 13:15           ` Konrad Dybcio
2025-12-05 22:17             ` Bjorn Andersson
2025-12-08 17:01               ` Mukesh Ojha
2025-12-17 13:09               ` Konrad Dybcio
2025-12-05 22:21       ` Bjorn Andersson
2025-12-08 14:25         ` Mukesh Ojha
2025-12-05 22:40   ` Bjorn Andersson
2025-12-08 16:49     ` Mukesh Ojha
2025-12-09 10:45       ` Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 12/14] remoteproc: pas: Extend parse_fw callback to fetch resources via SMC call Mukesh Ojha
2025-11-24 11:20   ` Konrad Dybcio
2025-11-21 11:01 ` [PATCH v8 13/14] remoteproc: qcom: pas: Enable Secure PAS support with IOMMU managed by Linux Mukesh Ojha
2025-11-24 11:31   ` Konrad Dybcio
2025-11-24 12:03     ` Mukesh Ojha
2025-11-26 16:40       ` Bjorn Andersson
2025-11-27  7:23         ` Mukesh Ojha
2025-11-21 11:01 ` [PATCH v8 14/14] arm64: dts: qcom: Add EL2 overlay for Lemans Mukesh Ojha
2025-12-05 23:00   ` Bjorn Andersson
2025-12-08 14:21     ` Mukesh Ojha
2025-11-21 11:27 ` Bryan O'Donoghue [this message]
2025-11-21 11:37   ` [PATCH v8 00/14] Peripheral Image Loader support for Qualcomm SoCs running Linux host at EL2 Mukesh Ojha
2025-11-21 15:08     ` Konrad Dybcio
2025-11-24  6:45       ` Mukesh Ojha
2025-11-24 11:33         ` Konrad Dybcio
2025-11-24 15:53           ` Mukesh Ojha
2025-11-27 10:25     ` Bryan O'Donoghue
2025-12-02  8:36       ` Mukesh Ojha
2025-12-02 10:13         ` Vikash Garodia
2025-12-02 21:24           ` Bjorn Andersson
2025-12-03  5:18             ` Vikash Garodia
2025-12-05 21:18               ` Dmitry Baryshkov
2025-12-17 10:08                 ` Vikash Garodia
2025-12-17 11:43                   ` Konrad Dybcio
2025-12-05 21:45               ` Bjorn Andersson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0156c327-b867-481e-af24-679f037bfa56@linaro.org \
    --to=bryan.odonoghue@linaro.org \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mukesh.ojha@oss.qualcomm.com \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).