All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Gerhold <stephan.gerhold@linaro.org>
To: Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Vikash Garodia <quic_vgarodia@quicinc.com>,
	Dikshita Agarwal <quic_dikshita@quicinc.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-media@vger.kernel.org, linux-remoteproc@vger.kernel.org
Subject: Re: [PATCH v2 11/11] media: iris: Enable Secure PAS support with IOMMU managed by Linux
Date: Wed, 20 Aug 2025 15:39:14 +0200	[thread overview]
Message-ID: <aKXQAoXZyR6SRPAA@linaro.org> (raw)
In-Reply-To: <20250820115659.kkngraove46wemxv@hu-mojha-hyd.qualcomm.com>

On Wed, Aug 20, 2025 at 05:26:59PM +0530, Mukesh Ojha wrote:
> On Wed, Aug 20, 2025 at 10:46:31AM +0200, Stephan Gerhold wrote:
> > On Tue, Aug 19, 2025 at 10:24:46PM +0530, Mukesh Ojha wrote:
> > > Most Qualcomm platforms feature a proprietary hypervisor (such as Gunyah
> > > or QHEE), which typically handles IOMMU configuration. This includes
> > > mapping memory regions and device memory resources for remote processors
> > > by intercepting qcom_scm_pas_auth_and_reset() calls. These mappings are
> > > later removed during teardown. Additionally, SHM bridge setup is required
> > > to enable memory protection for both remoteproc metadata and its memory
> > > regions.
> > > 
> > > When the hypervisor is absent, the operating system must perform these
> > > configurations instead.
> > > 
> > > Support for handling IOMMU and SHM setup in the absence of a hypervisor
> > > is now in place. Extend the Iris driver to enable this functionality on
> > > platforms where IOMMU is managed by Linux (i.e., non-Gunyah, non-QHEE).
> > > 
> > > Additionally, the Iris driver must map the firmware and its required
> > > resources to the firmware SID, which is now specified via the device tree.
> > > 
> > > Co-developed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> > > Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> > > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > > ---
> > >  drivers/media/platform/qcom/iris/iris_core.c  |   9 +-
> > >  drivers/media/platform/qcom/iris/iris_core.h  |   6 +
> > >  .../media/platform/qcom/iris/iris_firmware.c  | 156 ++++++++++++++++--
> > >  .../media/platform/qcom/iris/iris_firmware.h  |   2 +
> > >  4 files changed, 155 insertions(+), 18 deletions(-)
> > > 
> > > [...]
> > > diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c
> > > index f1b5cd56db32..e3f2fe5c9d7a 100644
> > > --- a/drivers/media/platform/qcom/iris/iris_firmware.c
> > > +++ b/drivers/media/platform/qcom/iris/iris_firmware.c
> > > @@ -3,10 +3,18 @@
> > >   * Copyright (c) 2022-2024 Qualcomm Innovation Center, Inc. All rights reserved.
> > >   */
> > >  
> > > +#include <linux/device.h>
> > >  #include <linux/firmware.h>
> > > -#include <linux/firmware/qcom/qcom_scm.h>
> > > +#include <linux/kernel.h>
> > > +#include <linux/iommu.h>
> > > +#include <linux/io.h>
> > > +#include <linux/of.h>
> > >  #include <linux/of_address.h>
> > >  #include <linux/of_reserved_mem.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/of_device.h>
> > > +#include <linux/firmware/qcom/qcom_scm.h>
> > > +#include <linux/sizes.h>
> > >  #include <linux/soc/qcom/mdt_loader.h>
> > >  
> > >  #include "iris_core.h"
> > > @@ -17,15 +25,14 @@
> > >  static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
> > >  {
> > >  	u32 pas_id = core->iris_platform_data->pas_id;
> > > +	struct qcom_scm_pas_ctx *ctx;
> > >  	const struct firmware *firmware = NULL;
> > >  	struct device *dev = core->dev;
> > > -	struct reserved_mem *rmem;
> > > -	struct device_node *node;
> > > -	phys_addr_t mem_phys;
> > > -	size_t res_size;
> > > -	ssize_t fw_size;
> > > -	void *mem_virt;
> > > -	int ret;
> > > +	struct reserved_mem *rmem = NULL;
> > > +	struct device_node *node = NULL;
> > > +	ssize_t fw_size = 0;
> > > +	void *mem_virt = NULL;
> > > +	int ret = 0;
> > >  
> > >  	if (strlen(fw_name) >= MAX_FIRMWARE_NAME_SIZE - 4)
> > >  		return -EINVAL;
> > > @@ -39,36 +46,64 @@ static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
> > >  	if (!rmem)
> > >  		return -EINVAL;
> > >  
> > > -	mem_phys = rmem->base;
> > > -	res_size = rmem->size;
> > > +	if (core->has_iommu)
> > > +		dev = core->fw.dev;
> > >  
> > > +	ctx = qcom_scm_pas_ctx_init(dev, pas_id, rmem->base, rmem->size, false);
> > > +	if (!ctx)
> > > +		return -ENOMEM;
> > > +
> > > +	ctx->has_iommu = core->has_iommu;
> > >  	ret = request_firmware(&firmware, fw_name, dev);
> > >  	if (ret)
> > >  		return ret;
> > >  
> > >  	fw_size = qcom_mdt_get_size(firmware);
> > > -	if (fw_size < 0 || res_size < (size_t)fw_size) {
> > > +	if (fw_size < 0 || rmem->size < (size_t)fw_size) {
> > >  		ret = -EINVAL;
> > >  		goto err_release_fw;
> > >  	}
> > >  
> > > -	mem_virt = memremap(mem_phys, res_size, MEMREMAP_WC);
> > > +	mem_virt = memremap(rmem->base, rmem->size, MEMREMAP_WC);
> > >  	if (!mem_virt) {
> > >  		ret = -ENOMEM;
> > >  		goto err_release_fw;
> > >  	}
> > >  
> > > -	ret = qcom_mdt_load(dev, firmware, fw_name,
> > > -			    pas_id, mem_virt, mem_phys, res_size, NULL);
> > > +	ret = qcom_mdt_pas_load(ctx, firmware, fw_name, mem_virt, NULL);
> > >  	if (ret)
> > >  		goto err_mem_unmap;
> > >  
> > > -	ret = qcom_scm_pas_auth_and_reset(pas_id);
> > > +	if (core->has_iommu) {
> > > +		ret = iommu_map(core->fw.iommu_domain, 0, rmem->base, rmem->size,
> > > +				IOMMU_READ | IOMMU_WRITE | IOMMU_PRIV, GFP_KERNEL);
> > 
> > What is the use case for IOMMU_PRIV here? You don't have this flag for
> > the qcom_q6v5_pas change.
> 
> This is there for historic regions, I may not have complete information about why
> is it required but the reference is taken from venus support for chrome.
> 

Setting IOMMU_PRIV results in omitting the ARM_LPAE_PTE_AP_UNPRIV bit in
the IOMMU page tables - have you checked if QHEE sets this? Ideally we
want to do the same QHEE would normally do.

Also, please add a define for the 0 numbere here similar to

#define VENUS_FW_START_ADDR		0x0

It's quite hard to see that this is not an identity-mapping like for
qcom_q6v5_pas.

>  
> > > +		if (ret)
> > > +			goto err_mem_unmap;
> > > +
> > > +		/*
> > > +		 * Firmware has no support for resource table for now, so, lets
> > > +		 * pass NULL and zero for input resource table and input resource
> > > +		 * table respectively.
> > > +		 */
> > > +		ret = qcom_mdt_pas_map_devmem_rscs(ctx, core->fw.iommu_domain, NULL, 0);
> > > +		if (ret)
> > > +			goto err_unmap_carveout;
> > > +	}
> > > +
> > > +	ret = qcom_scm_pas_prepare_and_auth_reset(ctx);
> > >  	if (ret)
> > > -		goto err_mem_unmap;
> > > +		goto err_unmap_devmem_rscs;
> > > +
> > > +	core->fw.ctx = ctx;
> > >  
> > >  	return ret;
> > >  
> > > +err_unmap_devmem_rscs:
> > > +	if (core->has_iommu)
> > > +		qcom_mdt_pas_unmap_devmem_rscs(ctx, core->fw.iommu_domain);
> > > +err_unmap_carveout:
> > > +	if (core->has_iommu)
> > > +		iommu_unmap(core->fw.iommu_domain, 0, rmem->size);
> > >  err_mem_unmap:
> > >  	memunmap(mem_virt);
> > >  err_release_fw:
> > > @@ -109,10 +144,97 @@ int iris_fw_load(struct iris_core *core)
> > >  
> > >  int iris_fw_unload(struct iris_core *core)
> > >  {
> > > -	return qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
> > > +	struct qcom_scm_pas_ctx *ctx;
> > > +	int ret;
> > > +
> > > +	ctx = core->fw.ctx;
> > > +	ret = qcom_scm_pas_shutdown(ctx->peripheral);
> > > +	if (core->has_iommu) {
> > > +		iommu_unmap(core->fw.iommu_domain, 0, ctx->mem_size);
> > > +		qcom_mdt_pas_unmap_devmem_rscs(ctx, core->fw.iommu_domain);
> > > +	}
> > > +
> > > +	return ret;
> > >  }
> > >  
> > >  int iris_set_hw_state(struct iris_core *core, bool resume)
> > >  {
> > >  	return qcom_scm_set_remote_state(resume, 0);
> > >  }
> > > +
> > > +int iris_fw_init(struct iris_core *core)
> > > +{
> > > +	struct platform_device_info info;
> > > +	struct iommu_domain *iommu_dom;
> > > +	struct platform_device *pdev;
> > > +	struct device_node *np;
> > > +	int ret;
> > > +
> > > +	np = of_get_child_by_name(core->dev->of_node, "video-firmware");
> > > +	if (!np)
> > > +		return 0;
> > 
> > You need a dt-bindings change for this as well. This is documented only
> > for Venus.
> 
> You are right, wanted to send device tree and binding support separately.
> But if required, will add with the series in the next version.
> 

You can send device tree changes separately, but dt-binding changes
always need to come before the driver changes.

Thanks,
Stephan

  reply	other threads:[~2025-08-20 13:39 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-19 16:54 [PATCH v2 00/11] Peripheral Image Loader support for Qualcomm SoCs running Linux host at EL2 Mukesh Ojha
2025-08-19 16:54 ` [PATCH v2 01/11] firmware: qcom_scm: Introduce PAS context initialization helper Mukesh Ojha
2025-08-19 17:17   ` Pavan Kondeti
2025-08-20  6:19     ` Mukesh Ojha
2025-08-20 11:40   ` Bryan O'Donoghue
2025-08-20 12:28     ` Mukesh Ojha
2025-09-13 14:54   ` Bryan O'Donoghue
2025-08-19 16:54 ` [PATCH v2 02/11] soc: qcom: mdtloader: Add context aware qcom_mdt_pas_load() helper Mukesh Ojha
2025-08-20 11:48   ` Bryan O'Donoghue
2025-08-20 12:25     ` Mukesh Ojha
2025-09-03 15:03   ` Bryan O'Donoghue
2025-09-04  9:52     ` Mukesh Ojha
2025-09-04 10:15       ` Bryan O'Donoghue
2025-09-04 11:43         ` Mukesh Ojha
2025-08-19 16:54 ` [PATCH v2 03/11] firmware: qcom_scm: Add a prep version of auth_and_reset function Mukesh Ojha
2025-08-20 12:03   ` Bryan O'Donoghue
2025-08-20 12:24     ` Mukesh Ojha
2025-08-19 16:54 ` [PATCH v2 04/11] firmware: qcom_scm: Simplify qcom_scm_pas_init_image() Mukesh Ojha
2025-08-21 14:36   ` Bryan O'Donoghue
2025-08-21 16:29     ` Mukesh Ojha
2025-08-19 16:54 ` [PATCH v2 05/11] firmware: qcom_scm: Add shmbridge support to pas_init/release function Mukesh Ojha
2025-08-21 15:23   ` Bryan O'Donoghue
2025-08-21 17:03     ` Mukesh Ojha
2025-08-22 16:52       ` Mukesh Ojha
2025-08-22 23:13       ` Bryan O'Donoghue
2025-08-19 16:54 ` [PATCH v2 06/11] remoteproc: Move resource table data structure to its own header Mukesh Ojha
2025-08-20  8:12   ` Stephan Gerhold
2025-08-20 15:18     ` Mukesh Ojha
2025-08-20 15:31       ` Stephan Gerhold
2025-08-22  7:56         ` Mukesh Ojha
2025-08-20 16:32       ` Mukesh Ojha
2025-08-20 16:53         ` Stephan Gerhold
2025-08-22  9:21           ` Mukesh Ojha
2025-08-22  8:35         ` Krzysztof Kozlowski
2025-08-22  9:30           ` Mukesh Ojha
2025-08-19 16:54 ` [PATCH v2 07/11] firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table Mukesh Ojha
2025-08-21 15:05   ` Krzysztof Kozlowski
2025-08-21 17:20     ` Mukesh Ojha
2025-08-22  6:22       ` Krzysztof Kozlowski
2025-08-22  7:21         ` Mukesh Ojha
2025-08-22  8:30         ` Krzysztof Kozlowski
2025-08-19 16:54 ` [PATCH v2 08/11] soc: qcom: mdt_loader: Add helper functions to map and unmap resources Mukesh Ojha
2025-08-19 16:54 ` [PATCH v2 09/11] remoteproc: pas: Extend parse_fw callback to parse resource table Mukesh Ojha
2025-08-20  8:36   ` Stephan Gerhold
2025-08-20 11:14     ` Mukesh Ojha
2025-08-20 13:07       ` Stephan Gerhold
2025-08-21 14:49     ` Krzysztof Kozlowski
2025-08-21 17:41       ` Mukesh Ojha
2025-08-19 16:54 ` [PATCH v2 10/11] remoteproc: qcom: pas: Enable Secure PAS support with IOMMU managed by Linux Mukesh Ojha
2025-08-20  8:40   ` Stephan Gerhold
2025-08-20 12:03     ` Mukesh Ojha
2025-08-19 16:54 ` [PATCH v2 11/11] media: iris: " Mukesh Ojha
2025-08-20  8:46   ` Stephan Gerhold
2025-08-20 11:56     ` Mukesh Ojha
2025-08-20 13:39       ` Stephan Gerhold [this message]
2025-08-22  4:26         ` Vikash Garodia
2025-08-22  8:46           ` Stephan Gerhold
2025-08-22 15:06             ` Mukesh Ojha
2025-08-22 16:26               ` Stephan Gerhold
2025-08-22 16:40                 ` Mukesh Ojha
2025-08-23 20:43                   ` Stephan Gerhold
2025-08-25 11:19                     ` Mukesh Ojha
2025-09-08  8:23                       ` Stephan Gerhold
2025-09-09 12:19                         ` Mukesh Ojha
2025-09-09 14:03                           ` Bryan O'Donoghue
2025-08-20 11:33   ` Bryan O'Donoghue
2025-08-20 12:00     ` Mukesh Ojha
2025-08-22  8:45   ` Krzysztof Kozlowski
2025-08-22 15:13     ` Mukesh Ojha
2025-08-23 15:41       ` Krzysztof Kozlowski
2025-08-23 15:46         ` Krzysztof Kozlowski
2025-08-23 15:52           ` Krzysztof Kozlowski
2025-08-20 11:03 ` [PATCH v2 00/11] Peripheral Image Loader support for Qualcomm SoCs running Linux host at EL2 Bryan O'Donoghue
2025-08-20 11:22   ` Mukesh Ojha
2025-09-03 11:56     ` Konrad Dybcio
2025-09-03 13:31       ` Bryan O'Donoghue
2025-09-03 14:02         ` Dmitry Baryshkov
2025-09-03 14:05           ` Bryan O'Donoghue
2025-09-03 14:13           ` Bryan O'Donoghue
2025-09-03 14:21             ` Bryan O'Donoghue
2025-09-03 14:28             ` Dmitry Baryshkov

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=aKXQAoXZyR6SRPAA@linaro.org \
    --to=stephan.gerhold@linaro.org \
    --cc=abhinav.kumar@linux.dev \
    --cc=andersson@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mchehab@kernel.org \
    --cc=quic_dikshita@quicinc.com \
    --cc=quic_vgarodia@quicinc.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.