.../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 | 368 ++++++++++++++++++--- drivers/firmware/qcom/qcom_scm.h | 1 + drivers/remoteproc/qcom_q6v5_pas.c | 166 ++++++++-- drivers/soc/qcom/mdt_loader.c | 42 ++- include/linux/firmware/qcom/qcom_scm.h | 30 +- include/linux/soc/qcom/mdt_loader.h | 22 +- 9 files changed, 577 insertions(+), 106 deletions(-)
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 .
Changes in v7: https://lore.kernel.org/lkml/20251104-kvm_rproc_v6-v6-0-7017b0adc24e@oss.qualcomm.com/
- Addressed Bryan suggestion to modify commit message on 2/14 .
- Repharsed commit message based on Krzysztof comment made on 1/14.
- Addressed Konrad suggestion
o To remove pas metadata data structure.
o Added his suggestion on adding retry in rsc_table SCM call.
o Added his rephrased version of comment made in 12/14
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.
- 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: Refactor 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 | 368 ++++++++++++++++++---
drivers/firmware/qcom/qcom_scm.h | 1 +
drivers/remoteproc/qcom_q6v5_pas.c | 166 ++++++++--
drivers/soc/qcom/mdt_loader.c | 42 ++-
include/linux/firmware/qcom/qcom_scm.h | 30 +-
include/linux/soc/qcom/mdt_loader.h | 22 +-
9 files changed, 577 insertions(+), 106 deletions(-)
---
base-commit: 88cbd8ac379cf5ce68b7efcfd4d1484a6871ee0b
change-id: 20251121-kvm_rproc_v8-5618000321fb
Best regards,
--
-Mukesh Ojha
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
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/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 ? 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-hyd.qualcomm.com/ [2] https://lore.kernel.org/lkml/cover.1762235099.git.charan.kalla@oss.qualcomm.com/ > > --- > bod -- -Mukesh Ojha
On 21/11/2025 11:37, Mukesh Ojha wrote:
>> 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
> hyd.qualcomm.com/
Why though ?
You are mixing together the issue of multiple SIDs and the original
loading of firmware which could easily reuse the venus method of
&iris {
video-firmware {
iommus = <&apss_smmu hex>;
};
};
That binding got dropped because it was unused in Iris.
https://lore.kernel.org/lkml/05d40a3b-cc13-b704-cac7-0ecbeea0e59d@quicinc.com/
I still fail to see why we are waiting for multi-cell IOMMU to land,
when it is expected to and what the VPU enablement story is upstream in
the meantime.
Blocked it seems.
---
bod
On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
> On 21/11/2025 11:37, Mukesh Ojha wrote:
> > > 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
> > hyd.qualcomm.com/
>
> Why though ?
>
> You are mixing together the issue of multiple SIDs and the original loading
> of firmware which could easily reuse the venus method of
>
> &iris {
> video-firmware {
> iommus = <&apss_smmu hex>;
> };
> };
I completely understand what you are saying, and it would be very easy
for me to do that if it gets accepted. However, I doubt that the people
who raised this concern would agree with the approach.
I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
banks separately. I’ll leave this to @Vikas to answer.
Also, I do not want the video PIL discussion to be part of this series, as it could
unnecessarily give the impression that this series depends on it.
>
> That binding got dropped because it was unused in Iris.
>
> https://lore.kernel.org/lkml/05d40a3b-cc13-b704-cac7-0ecbeea0e59d@quicinc.com/
>
> I still fail to see why we are waiting for multi-cell IOMMU to land, when it
> is expected to and what the VPU enablement story is upstream in the
> meantime.
>
> Blocked it seems.
No, it is ongoing, there will be next version coming.
>
> ---
> bod
--
-Mukesh Ojha
On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
> On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
>> On 21/11/2025 11:37, Mukesh Ojha wrote:
>>>> 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
>>> hyd.qualcomm.com/
>>
>> Why though ?
>>
>> You are mixing together the issue of multiple SIDs and the original loading
>> of firmware which could easily reuse the venus method of
>>
>> &iris {
>> video-firmware {
>> iommus = <&apss_smmu hex>;
>> };
>> };
>
> I completely understand what you are saying, and it would be very easy
> for me to do that if it gets accepted. However, I doubt that the people
> who raised this concern would agree with the approach.
>
> I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
> banks separately. I’ll leave this to @Vikas to answer.
Not exactly as a separate sub-node, but i do like the idea of
introducing a simple iommu property, something like this, which Stephan
proposed earlier in the discussion [1]
firmware-iommus = <&apps_smmu ...>;
I understand that we are doing the iommu-map thing, but a property
exclusively for firmware like above look much simpler to me.
Dmitry/ Bryan/ Krzysztof if you are good with this, we can bring back
video in this series. Please share your thoughts on this.
Regards,
Vikash
[1] https://lore.kernel.org/lkml/aKooCFoV3ZYwOMRx@linaro.org/
>
> Also, I do not want the video PIL discussion to be part of this series, as it could
> unnecessarily give the impression that this series depends on it.
>
>>
>> That binding got dropped because it was unused in Iris.
>>
>> https://lore.kernel.org/lkml/05d40a3b-cc13-b704-cac7-0ecbeea0e59d@quicinc.com/
>>
>> I still fail to see why we are waiting for multi-cell IOMMU to land, when it
>> is expected to and what the VPU enablement story is upstream in the
>> meantime.
>>
>> Blocked it seems.
>
> No, it is ongoing, there will be next version coming.
>
>>
>> ---
>> bod
>
On Tue, Dec 02, 2025 at 03:43:17PM +0530, Vikash Garodia wrote:
>
> On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
> > On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
> > > On 21/11/2025 11:37, Mukesh Ojha wrote:
> > > > > 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
> > > > hyd.qualcomm.com/
> > >
> > > Why though ?
> > >
> > > You are mixing together the issue of multiple SIDs and the original loading
> > > of firmware which could easily reuse the venus method of
> > >
> > > &iris {
> > > video-firmware {
> > > iommus = <&apss_smmu hex>;
> > > };
> > > };
> >
> > I completely understand what you are saying, and it would be very easy
> > for me to do that if it gets accepted. However, I doubt that the people
> > who raised this concern would agree with the approach.
> >
> > I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
> > banks separately. I’ll leave this to @Vikas to answer.
>
> Not exactly as a separate sub-node, but i do like the idea of introducing a
> simple iommu property, something like this, which Stephan proposed earlier
> in the discussion [1]
>
> firmware-iommus = <&apps_smmu ...>;
>
> I understand that we are doing the iommu-map thing, but a property
> exclusively for firmware like above look much simpler to me.
>
"We know we need to find a generic solution to this very problem, but
while we work on that let's add this quick hack to the ABI"?
> Dmitry/ Bryan/ Krzysztof if you are good with this, we can bring back video
> in this series. Please share your thoughts on this.
>
Please let's keep these concerns separate, so that we don't hold this
series up further. Even if we choose to go by the subnode approach, in
the same time frame, it's better to discuss it separately.
Regards,
Bjorn
> Regards,
> Vikash
>
> [1] https://lore.kernel.org/lkml/aKooCFoV3ZYwOMRx@linaro.org/
>
> >
> > Also, I do not want the video PIL discussion to be part of this series, as it could
> > unnecessarily give the impression that this series depends on it.
> >
> > >
> > > That binding got dropped because it was unused in Iris.
> > >
> > > https://lore.kernel.org/lkml/05d40a3b-cc13-b704-cac7-0ecbeea0e59d@quicinc.com/
> > >
> > > I still fail to see why we are waiting for multi-cell IOMMU to land, when it
> > > is expected to and what the VPU enablement story is upstream in the
> > > meantime.
> > >
> > > Blocked it seems.
> >
> > No, it is ongoing, there will be next version coming.
> >
> > >
> > > ---
> > > bod
> >
>
On 12/3/2025 2:54 AM, Bjorn Andersson wrote:
> On Tue, Dec 02, 2025 at 03:43:17PM +0530, Vikash Garodia wrote:
>>
>> On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
>>> On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
>>>> On 21/11/2025 11:37, Mukesh Ojha wrote:
>>>>>> 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
>>>>> hyd.qualcomm.com/
>>>>
>>>> Why though ?
>>>>
>>>> You are mixing together the issue of multiple SIDs and the original loading
>>>> of firmware which could easily reuse the venus method of
>>>>
>>>> &iris {
>>>> video-firmware {
>>>> iommus = <&apss_smmu hex>;
>>>> };
>>>> };
>>>
>>> I completely understand what you are saying, and it would be very easy
>>> for me to do that if it gets accepted. However, I doubt that the people
>>> who raised this concern would agree with the approach.
>>>
>>> I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
>>> banks separately. I’ll leave this to @Vikas to answer.
>>
>> Not exactly as a separate sub-node, but i do like the idea of introducing a
>> simple iommu property, something like this, which Stephan proposed earlier
>> in the discussion [1]
>>
>> firmware-iommus = <&apps_smmu ...>;
>>
>> I understand that we are doing the iommu-map thing, but a property
>> exclusively for firmware like above look much simpler to me.
>>
>
> "We know we need to find a generic solution to this very problem, but
> while we work on that let's add this quick hack to the ABI"?
I would not call that as hack, rather a simpler solution instead of
packing everything into the generic iommu-map.
"firmware-iommus" is much more readable to interpret something running
in el2 mode, than digging into function ids inside iommu-map and then
matching it up with specific SIDs to confirm.
>> Dmitry/ Bryan/ Krzysztof if you are good with this, we can bring back video
>> in this series. Please share your thoughts on this.
>>
>
> Please let's keep these concerns separate, so that we don't hold this
> series up further. Even if we choose to go by the subnode approach, in
> the same time frame, it's better to discuss it separately.
>
ACK.
> Regards,
> Bjorn
>
>> Regards,
>> Vikash
>>
>> [1] https://lore.kernel.org/lkml/aKooCFoV3ZYwOMRx@linaro.org/
>>
>>>
>>> Also, I do not want the video PIL discussion to be part of this series, as it could
>>> unnecessarily give the impression that this series depends on it.
>>>
>>>>
>>>> That binding got dropped because it was unused in Iris.
>>>>
>>>> https://lore.kernel.org/lkml/05d40a3b-cc13-b704-cac7-0ecbeea0e59d@quicinc.com/
>>>>
>>>> I still fail to see why we are waiting for multi-cell IOMMU to land, when it
>>>> is expected to and what the VPU enablement story is upstream in the
>>>> meantime.
>>>>
>>>> Blocked it seems.
>>>
>>> No, it is ongoing, there will be next version coming.
>>>
>>>>
>>>> ---
>>>> bod
>>>
>>
On Wed, Dec 03, 2025 at 10:48:14AM +0530, Vikash Garodia wrote:
>
> On 12/3/2025 2:54 AM, Bjorn Andersson wrote:
> > On Tue, Dec 02, 2025 at 03:43:17PM +0530, Vikash Garodia wrote:
> > >
> > > On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
> > > > On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
> > > > > On 21/11/2025 11:37, Mukesh Ojha wrote:
> > > > > > > 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
> > > > > > hyd.qualcomm.com/
> > > > >
> > > > > Why though ?
> > > > >
> > > > > You are mixing together the issue of multiple SIDs and the original loading
> > > > > of firmware which could easily reuse the venus method of
> > > > >
> > > > > &iris {
> > > > > video-firmware {
> > > > > iommus = <&apss_smmu hex>;
> > > > > };
> > > > > };
> > > >
> > > > I completely understand what you are saying, and it would be very easy
> > > > for me to do that if it gets accepted. However, I doubt that the people
> > > > who raised this concern would agree with the approach.
> > > >
> > > > I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
> > > > banks separately. I’ll leave this to @Vikas to answer.
> > >
> > > Not exactly as a separate sub-node, but i do like the idea of introducing a
> > > simple iommu property, something like this, which Stephan proposed earlier
> > > in the discussion [1]
> > >
> > > firmware-iommus = <&apps_smmu ...>;
> > >
> > > I understand that we are doing the iommu-map thing, but a property
> > > exclusively for firmware like above look much simpler to me.
> > >
> >
> > "We know we need to find a generic solution to this very problem, but
> > while we work on that let's add this quick hack to the ABI"?
>
> I would not call that as hack, rather a simpler solution instead of packing
> everything into the generic iommu-map.
>
The solution might not be a hack, throwing it in there quickly as a
one-off is a hack.
> "firmware-iommus" is much more readable to interpret something running in
> el2 mode, than digging into function ids inside iommu-map and then matching
> it up with specific SIDs to confirm.
>
Your argument is sensible, I would need to see (or write) the code
you're referring to, in order to be able to form an opinion. But having
two separate ways to express the "same" thing deserves more
consideration.
Looking at how the SMMU configuration will look in the next generation
might even speak in favor of what you're suggesting. Let's sync up after
Plumbers.
Regards,
Bjorn
> > > Dmitry/ Bryan/ Krzysztof if you are good with this, we can bring back video
> > > in this series. Please share your thoughts on this.
> > >
> >
> > Please let's keep these concerns separate, so that we don't hold this
> > series up further. Even if we choose to go by the subnode approach, in
> > the same time frame, it's better to discuss it separately.
> >
>
> ACK.
>
> > Regards,
> > Bjorn
> >
> > > Regards,
> > > Vikash
> > >
> > > [1] https://lore.kernel.org/lkml/aKooCFoV3ZYwOMRx@linaro.org/
> > >
> > > >
> > > > Also, I do not want the video PIL discussion to be part of this series, as it could
> > > > unnecessarily give the impression that this series depends on it.
> > > >
> > > > >
> > > > > That binding got dropped because it was unused in Iris.
> > > > >
> > > > > https://lore.kernel.org/lkml/05d40a3b-cc13-b704-cac7-0ecbeea0e59d@quicinc.com/
> > > > >
> > > > > I still fail to see why we are waiting for multi-cell IOMMU to land, when it
> > > > > is expected to and what the VPU enablement story is upstream in the
> > > > > meantime.
> > > > >
> > > > > Blocked it seems.
> > > >
> > > > No, it is ongoing, there will be next version coming.
> > > >
> > > > >
> > > > > ---
> > > > > bod
> > > >
> > >
>
On Wed, Dec 03, 2025 at 10:48:14AM +0530, Vikash Garodia wrote:
>
> On 12/3/2025 2:54 AM, Bjorn Andersson wrote:
> > On Tue, Dec 02, 2025 at 03:43:17PM +0530, Vikash Garodia wrote:
> > >
> > > On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
> > > > On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
> > > > > On 21/11/2025 11:37, Mukesh Ojha wrote:
> > > > > > > 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
> > > > > > hyd.qualcomm.com/
> > > > >
> > > > > Why though ?
> > > > >
> > > > > You are mixing together the issue of multiple SIDs and the original loading
> > > > > of firmware which could easily reuse the venus method of
> > > > >
> > > > > &iris {
> > > > > video-firmware {
> > > > > iommus = <&apss_smmu hex>;
> > > > > };
> > > > > };
> > > >
> > > > I completely understand what you are saying, and it would be very easy
> > > > for me to do that if it gets accepted. However, I doubt that the people
> > > > who raised this concern would agree with the approach.
> > > >
> > > > I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
> > > > banks separately. I’ll leave this to @Vikas to answer.
> > >
> > > Not exactly as a separate sub-node, but i do like the idea of introducing a
> > > simple iommu property, something like this, which Stephan proposed earlier
> > > in the discussion [1]
> > >
> > > firmware-iommus = <&apps_smmu ...>;
> > >
> > > I understand that we are doing the iommu-map thing, but a property
> > > exclusively for firmware like above look much simpler to me.
> > >
> >
> > "We know we need to find a generic solution to this very problem, but
> > while we work on that let's add this quick hack to the ABI"?
>
> I would not call that as hack, rather a simpler solution instead of packing
> everything into the generic iommu-map.
>
> "firmware-iommus" is much more readable to interpret something running in
> el2 mode, than digging into function ids inside iommu-map and then matching
> it up with specific SIDs to confirm.
If you want it formally, NAK from my side for firmware-iommus. Either
reuse an existing approach (at least it makese sense from the historical
point of view) or introduce a generic approach, which is iommu-maps. The
proposed firmware-iommus is definitely a hack around the IOMMU
properties.
But it's really off-topic here.
> > > Dmitry/ Bryan/ Krzysztof if you are good with this, we can bring back video
> > > in this series. Please share your thoughts on this.
> > >
> >
> > Please let's keep these concerns separate, so that we don't hold this
> > series up further. Even if we choose to go by the subnode approach, in
> > the same time frame, it's better to discuss it separately.
> >
>
> ACK.
>
> > Regards,
> > Bjorn
> >
> > > Regards,
> > > Vikash
> > >
> > > [1] https://lore.kernel.org/lkml/aKooCFoV3ZYwOMRx@linaro.org/
> > >
> > > >
> > > > Also, I do not want the video PIL discussion to be part of this series, as it could
> > > > unnecessarily give the impression that this series depends on it.
> > > >
> > > > >
> > > > > That binding got dropped because it was unused in Iris.
> > > > >
> > > > > https://lore.kernel.org/lkml/05d40a3b-cc13-b704-cac7-0ecbeea0e59d@quicinc.com/
> > > > >
> > > > > I still fail to see why we are waiting for multi-cell IOMMU to land, when it
> > > > > is expected to and what the VPU enablement story is upstream in the
> > > > > meantime.
> > > > >
> > > > > Blocked it seems.
> > > >
> > > > No, it is ongoing, there will be next version coming.
> > > >
> > > > >
> > > > > ---
> > > > > bod
> > > >
> > >
>
--
With best wishes
Dmitry
On 12/6/2025 2:48 AM, Dmitry Baryshkov wrote:
> On Wed, Dec 03, 2025 at 10:48:14AM +0530, Vikash Garodia wrote:
>>
>> On 12/3/2025 2:54 AM, Bjorn Andersson wrote:
>>> On Tue, Dec 02, 2025 at 03:43:17PM +0530, Vikash Garodia wrote:
>>>>
>>>> On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
>>>>> On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
>>>>>> On 21/11/2025 11:37, Mukesh Ojha wrote:
>>>>>>>> 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
>>>>>>> hyd.qualcomm.com/
>>>>>>
>>>>>> Why though ?
>>>>>>
>>>>>> You are mixing together the issue of multiple SIDs and the original loading
>>>>>> of firmware which could easily reuse the venus method of
>>>>>>
>>>>>> &iris {
>>>>>> video-firmware {
>>>>>> iommus = <&apss_smmu hex>;
>>>>>> };
>>>>>> };
>>>>>
>>>>> I completely understand what you are saying, and it would be very easy
>>>>> for me to do that if it gets accepted. However, I doubt that the people
>>>>> who raised this concern would agree with the approach.
>>>>>
>>>>> I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
>>>>> banks separately. I’ll leave this to @Vikas to answer.
>>>>
>>>> Not exactly as a separate sub-node, but i do like the idea of introducing a
>>>> simple iommu property, something like this, which Stephan proposed earlier
>>>> in the discussion [1]
>>>>
>>>> firmware-iommus = <&apps_smmu ...>;
>>>>
>>>> I understand that we are doing the iommu-map thing, but a property
>>>> exclusively for firmware like above look much simpler to me.
>>>>
>>>
>>> "We know we need to find a generic solution to this very problem, but
>>> while we work on that let's add this quick hack to the ABI"?
>>
>> I would not call that as hack, rather a simpler solution instead of packing
>> everything into the generic iommu-map.
>>
>> "firmware-iommus" is much more readable to interpret something running in
>> el2 mode, than digging into function ids inside iommu-map and then matching
>> it up with specific SIDs to confirm.
>
> If you want it formally, NAK from my side for firmware-iommus. Either
> reuse an existing approach (at least it makese sense from the historical
> point of view) or introduce a generic approach, which is iommu-maps. The
> proposed firmware-iommus is definitely a hack around the IOMMU
> properties.
>
> But it's really off-topic here.
Infact i see a concern with the iommu-map approach for firmware SIDs.
Let say the hardware generates 10 SIDs, including firmware. So video
binding should describe those 10 SIDs and the DTS should have all those
10 SIDs as well, including firmware SID.
Given above, video driver cannot distinguish if the SOC is running in
EL2 (KVM) mode or Gunyah mode.
Could you please suggest if we can make it work with iommu-map approach
Regards,
Vikash
On 12/17/25 11:08 AM, Vikash Garodia wrote:
>
> On 12/6/2025 2:48 AM, Dmitry Baryshkov wrote:
>> On Wed, Dec 03, 2025 at 10:48:14AM +0530, Vikash Garodia wrote:
>>>
>>> On 12/3/2025 2:54 AM, Bjorn Andersson wrote:
>>>> On Tue, Dec 02, 2025 at 03:43:17PM +0530, Vikash Garodia wrote:
>>>>>
>>>>> On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
>>>>>> On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
>>>>>>> On 21/11/2025 11:37, Mukesh Ojha wrote:
>>>>>>>>> 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
>>>>>>>> hyd.qualcomm.com/
>>>>>>>
>>>>>>> Why though ?
>>>>>>>
>>>>>>> You are mixing together the issue of multiple SIDs and the original loading
>>>>>>> of firmware which could easily reuse the venus method of
>>>>>>>
>>>>>>> &iris {
>>>>>>> video-firmware {
>>>>>>> iommus = <&apss_smmu hex>;
>>>>>>> };
>>>>>>> };
>>>>>>
>>>>>> I completely understand what you are saying, and it would be very easy
>>>>>> for me to do that if it gets accepted. However, I doubt that the people
>>>>>> who raised this concern would agree with the approach.
>>>>>>
>>>>>> I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
>>>>>> banks separately. I’ll leave this to @Vikas to answer.
>>>>>
>>>>> Not exactly as a separate sub-node, but i do like the idea of introducing a
>>>>> simple iommu property, something like this, which Stephan proposed earlier
>>>>> in the discussion [1]
>>>>>
>>>>> firmware-iommus = <&apps_smmu ...>;
>>>>>
>>>>> I understand that we are doing the iommu-map thing, but a property
>>>>> exclusively for firmware like above look much simpler to me.
>>>>>
>>>>
>>>> "We know we need to find a generic solution to this very problem, but
>>>> while we work on that let's add this quick hack to the ABI"?
>>>
>>> I would not call that as hack, rather a simpler solution instead of packing
>>> everything into the generic iommu-map.
>>>
>>> "firmware-iommus" is much more readable to interpret something running in
>>> el2 mode, than digging into function ids inside iommu-map and then matching
>>> it up with specific SIDs to confirm.
>>
>> If you want it formally, NAK from my side for firmware-iommus. Either
>> reuse an existing approach (at least it makese sense from the historical
>> point of view) or introduce a generic approach, which is iommu-maps. The
>> proposed firmware-iommus is definitely a hack around the IOMMU
>> properties.
>>
>> But it's really off-topic here.
>
> Infact i see a concern with the iommu-map approach for firmware SIDs. Let say the hardware generates 10 SIDs, including firmware. So video binding should describe those 10 SIDs and the DTS should have all those 10 SIDs as well, including firmware SID.
> Given above, video driver cannot distinguish if the SOC is running in EL2 (KVM) mode or Gunyah mode.
EL2 vs Gunyah is not hard (something like is_hyp_mode_available()), but
again, this should all be calling some sort of is_gunyah() which would
come from the gunyah hyp drivers, which have seen no activity on lkml
for over a year..
Konrad
On 17/12/2025 11:43, Konrad Dybcio wrote:
> On 12/17/25 11:08 AM, Vikash Garodia wrote:
>>
>> On 12/6/2025 2:48 AM, Dmitry Baryshkov wrote:
>>> On Wed, Dec 03, 2025 at 10:48:14AM +0530, Vikash Garodia wrote:
>>>>
>>>> On 12/3/2025 2:54 AM, Bjorn Andersson wrote:
>>>>> On Tue, Dec 02, 2025 at 03:43:17PM +0530, Vikash Garodia wrote:
>>>>>>
>>>>>> On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
>>>>>>> On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
>>>>>>>> On 21/11/2025 11:37, Mukesh Ojha wrote:
>>>>>>>>>> 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
>>>>>>>>> hyd.qualcomm.com/
>>>>>>>>
>>>>>>>> Why though ?
>>>>>>>>
>>>>>>>> You are mixing together the issue of multiple SIDs and the original loading
>>>>>>>> of firmware which could easily reuse the venus method of
>>>>>>>>
>>>>>>>> &iris {
>>>>>>>> video-firmware {
>>>>>>>> iommus = <&apss_smmu hex>;
>>>>>>>> };
>>>>>>>> };
>>>>>>>
>>>>>>> I completely understand what you are saying, and it would be very easy
>>>>>>> for me to do that if it gets accepted. However, I doubt that the people
>>>>>>> who raised this concern would agree with the approach.
>>>>>>>
>>>>>>> I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
>>>>>>> banks separately. I’ll leave this to @Vikas to answer.
>>>>>>
>>>>>> Not exactly as a separate sub-node, but i do like the idea of introducing a
>>>>>> simple iommu property, something like this, which Stephan proposed earlier
>>>>>> in the discussion [1]
>>>>>>
>>>>>> firmware-iommus = <&apps_smmu ...>;
>>>>>>
>>>>>> I understand that we are doing the iommu-map thing, but a property
>>>>>> exclusively for firmware like above look much simpler to me.
>>>>>>
>>>>>
>>>>> "We know we need to find a generic solution to this very problem, but
>>>>> while we work on that let's add this quick hack to the ABI"?
>>>>
>>>> I would not call that as hack, rather a simpler solution instead of packing
>>>> everything into the generic iommu-map.
>>>>
>>>> "firmware-iommus" is much more readable to interpret something running in
>>>> el2 mode, than digging into function ids inside iommu-map and then matching
>>>> it up with specific SIDs to confirm.
>>>
>>> If you want it formally, NAK from my side for firmware-iommus. Either
>>> reuse an existing approach (at least it makese sense from the historical
>>> point of view) or introduce a generic approach, which is iommu-maps. The
>>> proposed firmware-iommus is definitely a hack around the IOMMU
>>> properties.
>>>
>>> But it's really off-topic here.
>>
>> Infact i see a concern with the iommu-map approach for firmware SIDs. Let say the hardware generates 10 SIDs, including firmware. So video binding should describe those 10 SIDs and the DTS should have all those 10 SIDs as well, including firmware SID.
>> Given above, video driver cannot distinguish if the SOC is running in EL2 (KVM) mode or Gunyah mode.
>
> EL2 vs Gunyah is not hard (something like is_hyp_mode_available()), but
> again, this should all be calling some sort of is_gunyah() which would
> come from the gunyah hyp drivers, which have seen no activity on lkml
> for over a year..
>
> Konrad
What exactly is the status of the iommu-map stuff and when is it likely
to land ?
We _already_ have thanks to chromeos a way to define this stuff in venus.
My €0.02 is 100% fine with iommu-map as a solution for VPU but then,
actually want to see it as part of the series solving the problem.
Else, we should reuse the venus approach.
Right now we have the worst of both worlds. Iris is blocked waiting on
iommu-map but the iommu-map series has dropped Iris support because -
reasons.
The very definition of being stuck between a rock and a hard place.
@Mukesh - can you add Iris support back into the series ? If so then is
it perfectly reasonable to proceed with iommu-map for Iris.
If not then we should just reuse the approach we have.
Either way I regard this series as broken right now, as it applies a
solution that excludes one of the primary users of that solution with no
view as to when that user gets enabled, worse still it requires
adaptation to the new solution but the proposer won't do that work...
It places Iris in a very invidious position.
So again I think if we can agree to add Iris support back into this
series then we should go ahead with implementing in Iris.
If not then the conclusion is Iris _won't_ use that solution and we go
with the previous venus solution.
Either way, the proposed series as is, is an effective blocker for Iris
so I'd like a commitment either to re-add or we agree it won't be added
at all.
Either way Iris gets unblocked.
---
bod
On Thu, Dec 18, 2025 at 04:32:01AM +0000, Bryan O'Donoghue wrote:
> On 17/12/2025 11:43, Konrad Dybcio wrote:
> > On 12/17/25 11:08 AM, Vikash Garodia wrote:
> > >
> > > On 12/6/2025 2:48 AM, Dmitry Baryshkov wrote:
> > > > On Wed, Dec 03, 2025 at 10:48:14AM +0530, Vikash Garodia wrote:
> > > > >
> > > > > On 12/3/2025 2:54 AM, Bjorn Andersson wrote:
> > > > > > On Tue, Dec 02, 2025 at 03:43:17PM +0530, Vikash Garodia wrote:
> > > > > > >
> > > > > > > On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
> > > > > > > > On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
> > > > > > > > > On 21/11/2025 11:37, Mukesh Ojha wrote:
> > > > > > > > > > > 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
> > > > > > > > > > hyd.qualcomm.com/
> > > > > > > > >
> > > > > > > > > Why though ?
> > > > > > > > >
> > > > > > > > > You are mixing together the issue of multiple SIDs and the original loading
> > > > > > > > > of firmware which could easily reuse the venus method of
> > > > > > > > >
> > > > > > > > > &iris {
> > > > > > > > > video-firmware {
> > > > > > > > > iommus = <&apss_smmu hex>;
> > > > > > > > > };
> > > > > > > > > };
> > > > > > > >
> > > > > > > > I completely understand what you are saying, and it would be very easy
> > > > > > > > for me to do that if it gets accepted. However, I doubt that the people
> > > > > > > > who raised this concern would agree with the approach.
> > > > > > > >
> > > > > > > > I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
> > > > > > > > banks separately. I’ll leave this to @Vikas to answer.
> > > > > > >
> > > > > > > Not exactly as a separate sub-node, but i do like the idea of introducing a
> > > > > > > simple iommu property, something like this, which Stephan proposed earlier
> > > > > > > in the discussion [1]
> > > > > > >
> > > > > > > firmware-iommus = <&apps_smmu ...>;
> > > > > > >
> > > > > > > I understand that we are doing the iommu-map thing, but a property
> > > > > > > exclusively for firmware like above look much simpler to me.
> > > > > > >
> > > > > >
> > > > > > "We know we need to find a generic solution to this very problem, but
> > > > > > while we work on that let's add this quick hack to the ABI"?
> > > > >
> > > > > I would not call that as hack, rather a simpler solution instead of packing
> > > > > everything into the generic iommu-map.
> > > > >
> > > > > "firmware-iommus" is much more readable to interpret something running in
> > > > > el2 mode, than digging into function ids inside iommu-map and then matching
> > > > > it up with specific SIDs to confirm.
> > > >
> > > > If you want it formally, NAK from my side for firmware-iommus. Either
> > > > reuse an existing approach (at least it makese sense from the historical
> > > > point of view) or introduce a generic approach, which is iommu-maps. The
> > > > proposed firmware-iommus is definitely a hack around the IOMMU
> > > > properties.
> > > >
> > > > But it's really off-topic here.
> > >
> > > Infact i see a concern with the iommu-map approach for firmware SIDs. Let say the hardware generates 10 SIDs, including firmware. So video binding should describe those 10 SIDs and the DTS should have all those 10 SIDs as well, including firmware SID.
> > > Given above, video driver cannot distinguish if the SOC is running in EL2 (KVM) mode or Gunyah mode.
> >
> > EL2 vs Gunyah is not hard (something like is_hyp_mode_available()), but
> > again, this should all be calling some sort of is_gunyah() which would
> > come from the gunyah hyp drivers, which have seen no activity on lkml
> > for over a year..
> >
> > Konrad
>
> What exactly is the status of the iommu-map stuff and when is it likely to
> land ?
>
> We _already_ have thanks to chromeos a way to define this stuff in venus.
>
And we already know that the way we do iommu definitions for both venus
and iris is broken (the non-firmware part).
> My €0.02 is 100% fine with iommu-map as a solution for VPU but then,
> actually want to see it as part of the series solving the problem.
>
> Else, we should reuse the venus approach.
>
> Right now we have the worst of both worlds. Iris is blocked waiting on
> iommu-map but the iommu-map series has dropped Iris support because -
> reasons.
>
> The very definition of being stuck between a rock and a hard place.
>
> @Mukesh - can you add Iris support back into the series ? If so then is it
> perfectly reasonable to proceed with iommu-map for Iris.
Please no, this series adds remoteproc support and I think we're ready
to merge the next iteration thereof. There's no reason to conflate the
two topics and delay the introduction of the remoteprocs.
>
> If not then we should just reuse the approach we have.
>
> Either way I regard this series as broken right now, as it applies a
> solution that excludes one of the primary users of that solution with no
> view as to when that user gets enabled, worse still it requires adaptation
> to the new solution but the proposer won't do that work...
Yes, it requires adaptation, but that's not because of this series, but
because the world has changed.
>
> It places Iris in a very invidious position.
>
> So again I think if we can agree to add Iris support back into this series
> then we should go ahead with implementing in Iris.
No, we can merge this series and then turn around and decide to do
exactly what you suggest without further delays - if that's what we
want.
>
> If not then the conclusion is Iris _won't_ use that solution and we go with
> the previous venus solution.
>
> Either way, the proposed series as is, is an effective blocker for Iris so
> I'd like a commitment either to re-add or we agree it won't be added at all.
>
Perhaps I'm misunderstanding what you're saying. How is this blocking
iris support? It adds the support pieces and doesn't touch iris, afaict
the thing blocking iris support is the agreement on how to model the
iommu for iris.
Regards,
Bjorn
> Either way Iris gets unblocked.
>
> ---
> bod
On 12/18/25 5:32 AM, Bryan O'Donoghue wrote:
> On 17/12/2025 11:43, Konrad Dybcio wrote:
>> On 12/17/25 11:08 AM, Vikash Garodia wrote:
>>>
>>> On 12/6/2025 2:48 AM, Dmitry Baryshkov wrote:
>>>> On Wed, Dec 03, 2025 at 10:48:14AM +0530, Vikash Garodia wrote:
>>>>>
>>>>> On 12/3/2025 2:54 AM, Bjorn Andersson wrote:
>>>>>> On Tue, Dec 02, 2025 at 03:43:17PM +0530, Vikash Garodia wrote:
>>>>>>>
>>>>>>> On 12/2/2025 2:06 PM, Mukesh Ojha wrote:
>>>>>>>> On Thu, Nov 27, 2025 at 10:25:23AM +0000, Bryan O'Donoghue wrote:
>>>>>>>>> On 21/11/2025 11:37, Mukesh Ojha wrote:
>>>>>>>>>>> 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-
>>>>>>>>>> hyd.qualcomm.com/
>>>>>>>>>
>>>>>>>>> Why though ?
>>>>>>>>>
>>>>>>>>> You are mixing together the issue of multiple SIDs and the original loading
>>>>>>>>> of firmware which could easily reuse the venus method of
>>>>>>>>>
>>>>>>>>> &iris {
>>>>>>>>> video-firmware {
>>>>>>>>> iommus = <&apss_smmu hex>;
>>>>>>>>> };
>>>>>>>>> };
>>>>>>>>
>>>>>>>> I completely understand what you are saying, and it would be very easy
>>>>>>>> for me to do that if it gets accepted. However, I doubt that the people
>>>>>>>> who raised this concern would agree with the approach.
>>>>>>>>
>>>>>>>> I’m not sure if the video team would like to pursue pixel/non-pixel/firmware context
>>>>>>>> banks separately. I’ll leave this to @Vikas to answer.
>>>>>>>
>>>>>>> Not exactly as a separate sub-node, but i do like the idea of introducing a
>>>>>>> simple iommu property, something like this, which Stephan proposed earlier
>>>>>>> in the discussion [1]
>>>>>>>
>>>>>>> firmware-iommus = <&apps_smmu ...>;
>>>>>>>
>>>>>>> I understand that we are doing the iommu-map thing, but a property
>>>>>>> exclusively for firmware like above look much simpler to me.
>>>>>>>
>>>>>>
>>>>>> "We know we need to find a generic solution to this very problem, but
>>>>>> while we work on that let's add this quick hack to the ABI"?
>>>>>
>>>>> I would not call that as hack, rather a simpler solution instead of packing
>>>>> everything into the generic iommu-map.
>>>>>
>>>>> "firmware-iommus" is much more readable to interpret something running in
>>>>> el2 mode, than digging into function ids inside iommu-map and then matching
>>>>> it up with specific SIDs to confirm.
>>>>
>>>> If you want it formally, NAK from my side for firmware-iommus. Either
>>>> reuse an existing approach (at least it makese sense from the historical
>>>> point of view) or introduce a generic approach, which is iommu-maps. The
>>>> proposed firmware-iommus is definitely a hack around the IOMMU
>>>> properties.
>>>>
>>>> But it's really off-topic here.
>>>
>>> Infact i see a concern with the iommu-map approach for firmware SIDs. Let say the hardware generates 10 SIDs, including firmware. So video binding should describe those 10 SIDs and the DTS should have all those 10 SIDs as well, including firmware SID.
>>> Given above, video driver cannot distinguish if the SOC is running in EL2 (KVM) mode or Gunyah mode.
>>
>> EL2 vs Gunyah is not hard (something like is_hyp_mode_available()), but
>> again, this should all be calling some sort of is_gunyah() which would
>> come from the gunyah hyp drivers, which have seen no activity on lkml
>> for over a year..
>>
>> Konrad
>
> What exactly is the status of the iommu-map stuff and when is it likely to land ?
I don't know. This is unrelated to the issue this patchset is solving.
> We _already_ have thanks to chromeos a way to define this stuff in venus.
Which was.. heavily debated, let's call it, after Krzysztof noticed it exists
and you agreed it should not spread by leaving your r-b on:
6d3926a237b6 ("dt-bindings: media: qcom,sm8550-iris: Do not reference legacy venus properties")
> My €0.02 is 100% fine with iommu-map as a solution for VPU but then, actually want to see it as part of the series solving the problem.
>
> Else, we should reuse the venus approach.
>
> Right now we have the worst of both worlds. Iris is blocked waiting on iommu-map but the iommu-map series has dropped Iris support because - reasons.
I think you're replying to the wrong series.
> The very definition of being stuck between a rock and a hard place.
>
> @Mukesh - can you add Iris support back into the series ? If so then is it perfectly reasonable to proceed with iommu-map for Iris.
>
> If not then we should just reuse the approach we have.
>
> Either way I regard this series as broken right now, as it applies a solution that excludes one of the primary users of that solution with no view as to when that user gets enabled, worse still it requires adaptation to the new solution but the proposer won't do that work...
Why should Mukesh be required to carry your burden?
You (as the Iris maintainer) are a consumer of this new set of APIs provided in
this series, so one would expect that you can help test it by creating a
downstream patch (that would be nice to share), rebased on new revisions as
necessary and sharing feedback based on the drawbacks you notice.
> It places Iris in a very invidious position.
>
> So again I think if we can agree to add Iris support back into this series then we should go ahead with implementing in Iris.
>
> If not then the conclusion is Iris _won't_ use that solution and we go with the previous venus solution.
Because that surely won't get any pushback..
Konrad
> Either way, the proposed series as is, is an effective blocker for Iris so I'd like a commitment either to re-add or we agree it won't be added at all.
>
> Either way Iris gets unblocked.
>
> ---
> bod
On 11/21/25 12:37 PM, Mukesh Ojha wrote: > 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/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 ? > > 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-hyd.qualcomm.com/ > > [2] > https://lore.kernel.org/lkml/cover.1762235099.git.charan.kalla@oss.qualcomm.com/ I see that the following files call qcom_scm_pas_auth_.*(): drivers/firmware/qcom/qcom_scm.c drivers/gpu/drm/msm/adreno/adreno_gpu.c drivers/media/platform/qcom/iris/iris_firmware.c drivers/media/platform/qcom/venus/firmware.c drivers/net/ipa/ipa_main.c drivers/net/wireless/ath/ath12k/ahb.c drivers/remoteproc/qcom_q6v5_pas.c drivers/remoteproc/qcom_wcnss.c iris is difficult, rproc is done, adreno doesn't need it.. would ath12k_ahb or IPA be affected by this series as well? Konrad
On Fri, Nov 21, 2025 at 04:08:36PM +0100, Konrad Dybcio wrote: > On 11/21/25 12:37 PM, Mukesh Ojha wrote: > > 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/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 ? > > > > 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-hyd.qualcomm.com/ > > > > [2] > > https://lore.kernel.org/lkml/cover.1762235099.git.charan.kalla@oss.qualcomm.com/ > > I see that the following files call qcom_scm_pas_auth_.*(): > > drivers/firmware/qcom/qcom_scm.c > drivers/gpu/drm/msm/adreno/adreno_gpu.c > drivers/media/platform/qcom/iris/iris_firmware.c > drivers/media/platform/qcom/venus/firmware.c > drivers/net/ipa/ipa_main.c > drivers/net/wireless/ath/ath12k/ahb.c > drivers/remoteproc/qcom_q6v5_pas.c > drivers/remoteproc/qcom_wcnss.c > > iris is difficult, rproc is done, adreno doesn't need it.. > > would ath12k_ahb or IPA be affected by this series as well? Yes, they would be affected, and the modem as well, when Linux is running at EL2. However, I do not see them present in any of the QLi and targeted compute SoCs at the moment. Therefore, our firmware does not support it yet. > > Konrad -- -Mukesh Ojha
On 11/24/25 7:45 AM, Mukesh Ojha wrote: > On Fri, Nov 21, 2025 at 04:08:36PM +0100, Konrad Dybcio wrote: >> On 11/21/25 12:37 PM, Mukesh Ojha wrote: >>> 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/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 ? >>> >>> 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-hyd.qualcomm.com/ >>> >>> [2] >>> https://lore.kernel.org/lkml/cover.1762235099.git.charan.kalla@oss.qualcomm.com/ >> >> I see that the following files call qcom_scm_pas_auth_.*(): >> >> drivers/firmware/qcom/qcom_scm.c >> drivers/gpu/drm/msm/adreno/adreno_gpu.c >> drivers/media/platform/qcom/iris/iris_firmware.c >> drivers/media/platform/qcom/venus/firmware.c >> drivers/net/ipa/ipa_main.c >> drivers/net/wireless/ath/ath12k/ahb.c >> drivers/remoteproc/qcom_q6v5_pas.c >> drivers/remoteproc/qcom_wcnss.c >> >> iris is difficult, rproc is done, adreno doesn't need it.. >> >> would ath12k_ahb or IPA be affected by this series as well? > > Yes, they would be affected, and the modem as well, when Linux is > running at EL2. However, I do not see them present in any of the QLi and > targeted compute SoCs at the moment. Therefore, our firmware does not > support it yet. Hamoa's little brother should have ath12k_ahb.. and I assume IPA is present on at least some platforms where there's a modem (QCM6490?) Konrad
On Mon, Nov 24, 2025 at 12:33:47PM +0100, Konrad Dybcio wrote: > On 11/24/25 7:45 AM, Mukesh Ojha wrote: > > On Fri, Nov 21, 2025 at 04:08:36PM +0100, Konrad Dybcio wrote: > >> On 11/21/25 12:37 PM, Mukesh Ojha wrote: > >>> 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 > >>>>> [...] > >>>>> > >>>>> 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 ? > >>> > >>> 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/20251105081421.f6j7ks5bd4dfgr67@hu-mojha-hyd.qualcomm.com/ > >>> > >>> [2] > >>> https://lore.kernel.org/lkml/cover.1762235099.git.charan.kalla@oss.qualcomm.com/ > >> > >> I see that the following files call qcom_scm_pas_auth_.*(): > >> > >> drivers/firmware/qcom/qcom_scm.c > >> drivers/gpu/drm/msm/adreno/adreno_gpu.c > >> drivers/media/platform/qcom/iris/iris_firmware.c > >> drivers/media/platform/qcom/venus/firmware.c > >> drivers/net/ipa/ipa_main.c > >> drivers/net/wireless/ath/ath12k/ahb.c > >> drivers/remoteproc/qcom_q6v5_pas.c > >> drivers/remoteproc/qcom_wcnss.c > >> > >> iris is difficult, rproc is done, adreno doesn't need it.. > >> > >> would ath12k_ahb or IPA be affected by this series as well? > > > > Yes, they would be affected, and the modem as well, when Linux is > > running at EL2. However, I do not see them present in any of the QLi and > > targeted compute SoCs at the moment. Therefore, our firmware does not > > support it yet. > > Hamoa's little brother should have ath12k_ahb.. and I assume IPA is > present on at least some platforms where there's a modem (QCM6490?) Sure, We will add the support for IP's when there is a need for SoC running Linux at EL2 (backed by firmware). > > Konrad -- -Mukesh Ojha
© 2016 - 2026 Red Hat, Inc.