All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@kernel.org>
To: Jens Wiklander <jens.wiklander@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	op-tee@lists.trustedfirmware.org,
	linux-arm-kernel@lists.infradead.org,
	"Olivier Masse" <olivier.masse@nxp.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Yong Wu" <yong.wu@mediatek.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Brian Starkey" <Brian.Starkey@arm.com>,
	"John Stultz" <jstultz@google.com>,
	"T . J . Mercier" <tjmercier@google.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	azarrabi@qti.qualcomm.com,
	"Simona Vetter" <simona.vetter@ffwll.ch>,
	"Daniel Stone" <daniel@fooishbar.org>
Subject: Re: [PATCH v6 08/10] optee: support restricted memory allocation
Date: Tue, 25 Mar 2025 12:37:15 +0530	[thread overview]
Message-ID: <Z-JWIyd8cKyXQR0H@sumit-X1> (raw)
In-Reply-To: <20250305130634.1850178-9-jens.wiklander@linaro.org>

On Wed, Mar 05, 2025 at 02:04:14PM +0100, Jens Wiklander wrote:
> Add support in the OP-TEE backend driver for restricted memory
> allocation. The support is limited to only the SMC ABI and for secure
> video buffers.
> 
> OP-TEE is probed for the range of restricted physical memory and a
> memory pool allocator is initialized if OP-TEE have support for such
> memory.
> 
> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> ---
>  drivers/tee/optee/core.c    |  1 +
>  drivers/tee/optee/smc_abi.c | 44 +++++++++++++++++++++++++++++++++++--
>  2 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index c75fddc83576..c7fd8040480e 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -181,6 +181,7 @@ void optee_remove_common(struct optee *optee)
>  	tee_device_unregister(optee->supp_teedev);
>  	tee_device_unregister(optee->teedev);
>  
> +	tee_device_unregister_all_dma_heaps(optee->teedev);
>  	tee_shm_pool_free(optee->pool);
>  	optee_supp_uninit(&optee->supp);
>  	mutex_destroy(&optee->call_queue.mutex);
> diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
> index cfdae266548b..a14ff0b7d3b3 100644
> --- a/drivers/tee/optee/smc_abi.c
> +++ b/drivers/tee/optee/smc_abi.c
> @@ -1620,6 +1620,41 @@ static inline int optee_load_fw(struct platform_device *pdev,
>  }
>  #endif
>  
> +static int optee_sdp_pool_init(struct optee *optee)
> +{
> +	enum tee_dma_heap_id heap_id = TEE_DMA_HEAP_SECURE_VIDEO_PLAY;
> +	struct tee_rstmem_pool *pool;
> +	int rc;
> +
> +	if (optee->smc.sec_caps & OPTEE_SMC_SEC_CAP_SDP) {

Is this SDP capability an ABI yet since we haven't supported it in
upstream kernel? If no then can we rename it as
OPTEE_SMC_SEC_CAP_RSTMEM?

> +		union {
> +			struct arm_smccc_res smccc;
> +			struct optee_smc_get_sdp_config_result result;
> +		} res;
> +
> +		optee->smc.invoke_fn(OPTEE_SMC_GET_SDP_CONFIG, 0, 0, 0, 0, 0, 0,
> +				     0, &res.smccc);
> +		if (res.result.status != OPTEE_SMC_RETURN_OK) {
> +			pr_err("Secure Data Path service not available\n");
> +			return 0;
> +		}
> +
> +		pool = tee_rstmem_static_pool_alloc(res.result.start,
> +						    res.result.size);
> +		if (IS_ERR(pool))
> +			return PTR_ERR(pool);
> +
> +		rc = tee_device_register_dma_heap(optee->teedev, heap_id, pool);
> +		if (rc)
> +			goto err;
> +	}
> +
> +	return 0;
> +err:
> +	pool->ops->destroy_pool(pool);
> +	return rc;
> +}
> +
>  static int optee_probe(struct platform_device *pdev)
>  {
>  	optee_invoke_fn *invoke_fn;
> @@ -1715,7 +1750,7 @@ static int optee_probe(struct platform_device *pdev)
>  	optee = kzalloc(sizeof(*optee), GFP_KERNEL);
>  	if (!optee) {
>  		rc = -ENOMEM;
> -		goto err_free_pool;
> +		goto err_free_shm_pool;
>  	}
>  
>  	optee->ops = &optee_ops;
> @@ -1788,6 +1823,10 @@ static int optee_probe(struct platform_device *pdev)
>  		pr_info("Asynchronous notifications enabled\n");
>  	}
>  
> +	rc = optee_sdp_pool_init(optee);

s/optee_sdp_pool_init/optee_rstmem_pool_init/

-Sumit

> +	if (rc)
> +		goto err_notif_uninit;
> +
>  	/*
>  	 * Ensure that there are no pre-existing shm objects before enabling
>  	 * the shm cache so that there's no chance of receiving an invalid
> @@ -1823,6 +1862,7 @@ static int optee_probe(struct platform_device *pdev)
>  		optee_disable_shm_cache(optee);
>  	optee_smc_notif_uninit_irq(optee);
>  	optee_unregister_devices();
> +	tee_device_unregister_all_dma_heaps(optee->teedev);
>  err_notif_uninit:
>  	optee_notif_uninit(optee);
>  err_close_ctx:
> @@ -1839,7 +1879,7 @@ static int optee_probe(struct platform_device *pdev)
>  	tee_device_unregister(optee->teedev);
>  err_free_optee:
>  	kfree(optee);
> -err_free_pool:
> +err_free_shm_pool:
>  	tee_shm_pool_free(pool);
>  	if (memremaped_shm)
>  		memunmap(memremaped_shm);
> -- 
> 2.43.0
> 


WARNING: multiple messages have this Message-ID (diff)
From: Sumit Garg <sumit.garg@kernel.org>
To: op-tee@lists.trustedfirmware.org
Subject: Re: [PATCH v6 08/10] optee: support restricted memory allocation
Date: Tue, 25 Mar 2025 12:37:15 +0530	[thread overview]
Message-ID: <Z-JWIyd8cKyXQR0H@sumit-X1> (raw)
In-Reply-To: <20250305130634.1850178-9-jens.wiklander@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 3984 bytes --]

On Wed, Mar 05, 2025 at 02:04:14PM +0100, Jens Wiklander wrote:
> Add support in the OP-TEE backend driver for restricted memory
> allocation. The support is limited to only the SMC ABI and for secure
> video buffers.
> 
> OP-TEE is probed for the range of restricted physical memory and a
> memory pool allocator is initialized if OP-TEE have support for such
> memory.
> 
> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> ---
>  drivers/tee/optee/core.c    |  1 +
>  drivers/tee/optee/smc_abi.c | 44 +++++++++++++++++++++++++++++++++++--
>  2 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index c75fddc83576..c7fd8040480e 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -181,6 +181,7 @@ void optee_remove_common(struct optee *optee)
>  	tee_device_unregister(optee->supp_teedev);
>  	tee_device_unregister(optee->teedev);
>  
> +	tee_device_unregister_all_dma_heaps(optee->teedev);
>  	tee_shm_pool_free(optee->pool);
>  	optee_supp_uninit(&optee->supp);
>  	mutex_destroy(&optee->call_queue.mutex);
> diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
> index cfdae266548b..a14ff0b7d3b3 100644
> --- a/drivers/tee/optee/smc_abi.c
> +++ b/drivers/tee/optee/smc_abi.c
> @@ -1620,6 +1620,41 @@ static inline int optee_load_fw(struct platform_device *pdev,
>  }
>  #endif
>  
> +static int optee_sdp_pool_init(struct optee *optee)
> +{
> +	enum tee_dma_heap_id heap_id = TEE_DMA_HEAP_SECURE_VIDEO_PLAY;
> +	struct tee_rstmem_pool *pool;
> +	int rc;
> +
> +	if (optee->smc.sec_caps & OPTEE_SMC_SEC_CAP_SDP) {

Is this SDP capability an ABI yet since we haven't supported it in
upstream kernel? If no then can we rename it as
OPTEE_SMC_SEC_CAP_RSTMEM?

> +		union {
> +			struct arm_smccc_res smccc;
> +			struct optee_smc_get_sdp_config_result result;
> +		} res;
> +
> +		optee->smc.invoke_fn(OPTEE_SMC_GET_SDP_CONFIG, 0, 0, 0, 0, 0, 0,
> +				     0, &res.smccc);
> +		if (res.result.status != OPTEE_SMC_RETURN_OK) {
> +			pr_err("Secure Data Path service not available\n");
> +			return 0;
> +		}
> +
> +		pool = tee_rstmem_static_pool_alloc(res.result.start,
> +						    res.result.size);
> +		if (IS_ERR(pool))
> +			return PTR_ERR(pool);
> +
> +		rc = tee_device_register_dma_heap(optee->teedev, heap_id, pool);
> +		if (rc)
> +			goto err;
> +	}
> +
> +	return 0;
> +err:
> +	pool->ops->destroy_pool(pool);
> +	return rc;
> +}
> +
>  static int optee_probe(struct platform_device *pdev)
>  {
>  	optee_invoke_fn *invoke_fn;
> @@ -1715,7 +1750,7 @@ static int optee_probe(struct platform_device *pdev)
>  	optee = kzalloc(sizeof(*optee), GFP_KERNEL);
>  	if (!optee) {
>  		rc = -ENOMEM;
> -		goto err_free_pool;
> +		goto err_free_shm_pool;
>  	}
>  
>  	optee->ops = &optee_ops;
> @@ -1788,6 +1823,10 @@ static int optee_probe(struct platform_device *pdev)
>  		pr_info("Asynchronous notifications enabled\n");
>  	}
>  
> +	rc = optee_sdp_pool_init(optee);

s/optee_sdp_pool_init/optee_rstmem_pool_init/

-Sumit

> +	if (rc)
> +		goto err_notif_uninit;
> +
>  	/*
>  	 * Ensure that there are no pre-existing shm objects before enabling
>  	 * the shm cache so that there's no chance of receiving an invalid
> @@ -1823,6 +1862,7 @@ static int optee_probe(struct platform_device *pdev)
>  		optee_disable_shm_cache(optee);
>  	optee_smc_notif_uninit_irq(optee);
>  	optee_unregister_devices();
> +	tee_device_unregister_all_dma_heaps(optee->teedev);
>  err_notif_uninit:
>  	optee_notif_uninit(optee);
>  err_close_ctx:
> @@ -1839,7 +1879,7 @@ static int optee_probe(struct platform_device *pdev)
>  	tee_device_unregister(optee->teedev);
>  err_free_optee:
>  	kfree(optee);
> -err_free_pool:
> +err_free_shm_pool:
>  	tee_shm_pool_free(pool);
>  	if (memremaped_shm)
>  		memunmap(memremaped_shm);
> -- 
> 2.43.0
> 

  reply	other threads:[~2025-03-25  7:22 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-05 13:04 [PATCH v6 00/10] TEE subsystem for restricted dma-buf allocations Jens Wiklander
2025-03-05 13:04 ` Jens Wiklander
2025-03-05 13:04 ` [PATCH v6 01/10] tee: tee_device_alloc(): copy dma_mask from parent device Jens Wiklander
2025-03-05 13:04   ` Jens Wiklander
2025-03-10  8:56   ` Sumit Garg
2025-03-10  8:56     ` Sumit Garg
2025-03-05 13:04 ` [PATCH v6 02/10] optee: pass parent device to tee_device_alloc() Jens Wiklander
2025-03-05 13:04   ` Jens Wiklander
2025-03-10  8:57   ` Sumit Garg
2025-03-10  8:57     ` Sumit Garg
2025-03-05 13:04 ` [PATCH v6 03/10] optee: account for direction while converting parameters Jens Wiklander
2025-03-05 13:04   ` Jens Wiklander
2025-03-13 10:41   ` Sumit Garg
2025-03-13 10:41     ` Sumit Garg
2025-03-17  7:42     ` Jens Wiklander
2025-03-17  7:42       ` Jens Wiklander
2025-03-20  9:25       ` Sumit Garg
2025-03-20  9:25         ` Sumit Garg
2025-03-20 13:00         ` Jens Wiklander
2025-03-20 13:00           ` Jens Wiklander
2025-03-25  5:55           ` Sumit Garg
2025-03-25  5:55             ` Sumit Garg
2025-03-25  8:50             ` Jens Wiklander
2025-03-25  8:50               ` Jens Wiklander
2025-04-01  7:45               ` Sumit Garg
2025-04-01  7:45                 ` Sumit Garg
2025-04-01  8:21                 ` Jens Wiklander
2025-04-01  8:21                   ` Jens Wiklander
2025-03-05 13:04 ` [PATCH v6 04/10] optee: sync secure world ABI headers Jens Wiklander
2025-03-05 13:04   ` Jens Wiklander
2025-03-25  6:20   ` Sumit Garg
2025-03-25  6:20     ` Sumit Garg
2025-03-27  7:41     ` Jens Wiklander
2025-03-27  7:41       ` Jens Wiklander
2025-03-05 13:04 ` [PATCH v6 05/10] tee: implement restricted DMA-heap Jens Wiklander
2025-03-05 13:04   ` Jens Wiklander
2025-03-25  6:33   ` Sumit Garg
2025-03-25  6:33     ` Sumit Garg
2025-03-25 10:55     ` Jens Wiklander
2025-03-25 10:55       ` Jens Wiklander
2025-04-01  7:58       ` Sumit Garg
2025-04-01  7:58         ` Sumit Garg
2025-04-01  8:33         ` Jens Wiklander
2025-04-01  8:33           ` Jens Wiklander
2025-04-08  9:14           ` Sumit Garg
2025-04-08  9:14             ` Sumit Garg
2025-04-08 13:28             ` Jens Wiklander
2025-04-08 13:28               ` Jens Wiklander
2025-04-09 12:50               ` Sumit Garg
2025-04-09 12:50                 ` Sumit Garg
2025-04-10  6:49                 ` Jens Wiklander
2025-04-10  6:49                   ` Jens Wiklander
2025-03-05 13:04 ` [PATCH v6 06/10] tee: new ioctl to a register tee_shm from a dmabuf file descriptor Jens Wiklander
2025-03-05 13:04   ` Jens Wiklander
2025-03-25  6:50   ` Sumit Garg
2025-03-25  6:50     ` Sumit Garg
2025-03-25 11:17     ` Jens Wiklander
2025-03-25 11:17       ` Jens Wiklander
2025-04-01  8:46       ` Sumit Garg
2025-04-01  8:46         ` Sumit Garg
2025-04-01 13:50         ` Jens Wiklander
2025-04-01 13:50           ` Jens Wiklander
2025-03-05 13:04 ` [PATCH v6 07/10] tee: add tee_shm_alloc_cma_phys_mem() Jens Wiklander
2025-03-05 13:04   ` Jens Wiklander
2025-03-25  6:53   ` Sumit Garg
2025-03-25  6:53     ` Sumit Garg
2025-03-05 13:04 ` [PATCH v6 08/10] optee: support restricted memory allocation Jens Wiklander
2025-03-05 13:04   ` Jens Wiklander
2025-03-25  7:07   ` Sumit Garg [this message]
2025-03-25  7:07     ` Sumit Garg
2025-03-25 13:55     ` Jens Wiklander
2025-03-25 13:55       ` Jens Wiklander
2025-03-05 13:04 ` [PATCH v6 09/10] optee: FF-A: dynamic " Jens Wiklander
2025-03-05 13:04   ` Jens Wiklander
2025-03-25  7:41   ` Sumit Garg
2025-03-25  7:41     ` Sumit Garg
2025-03-27  8:07     ` Jens Wiklander
2025-03-27  8:07       ` Jens Wiklander
2025-04-01 10:13       ` Sumit Garg
2025-04-01 10:13         ` Sumit Garg
2025-04-01 12:26         ` Jens Wiklander
2025-04-01 12:26           ` Jens Wiklander
2025-04-08  9:20           ` Sumit Garg
2025-04-08  9:20             ` Sumit Garg
2025-04-08 13:39             ` Jens Wiklander
2025-04-08 13:39               ` Jens Wiklander
2025-04-09 10:01         ` David Hildenbrand
2025-04-09 10:01           ` David Hildenbrand
2025-04-09 13:19           ` Sumit Garg
2025-04-09 13:19             ` Sumit Garg
2025-03-05 13:04 ` [PATCH v6 10/10] optee: smc abi: " Jens Wiklander
2025-03-05 13:04   ` Jens Wiklander
2025-03-25  7:45   ` Sumit Garg
2025-03-25  7:45     ` Sumit Garg
2025-03-27  8:27 ` [PATCH v6 00/10] TEE subsystem for restricted dma-buf allocations Jens Wiklander
2025-03-27  8:27   ` Jens Wiklander

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=Z-JWIyd8cKyXQR0H@sumit-X1 \
    --to=sumit.garg@kernel.org \
    --cc=Brian.Starkey@arm.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=azarrabi@qti.qualcomm.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel@fooishbar.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jens.wiklander@linaro.org \
    --cc=jstultz@google.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=olivier.masse@nxp.com \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=simona.vetter@ffwll.ch \
    --cc=sumit.semwal@linaro.org \
    --cc=thierry.reding@gmail.com \
    --cc=tjmercier@google.com \
    --cc=yong.wu@mediatek.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.