Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Wed, 11 Oct 2023 17:17:38 -0500
From:   Andrew Halaney <ahalaney@redhat.com>
To:     Bartosz Golaszewski <brgl@bgdev.pl>
Cc:     Andy Gross <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        Elliot Berman <quic_eberman@quicinc.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
        Guru Das Srinagesh <quic_gurus@quicinc.com>,
        Maximilian Luz <luzmaximilian@gmail.com>,
        Alex Elder <elder@linaro.org>,
        Srini Kandagatla <srinivas.kandagatla@linaro.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, kernel@quicinc.com,
        Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH v3 13/15] firmware: qcom: tzmem: enable SHM Bridge support
Message-ID: <j543teo2apaugbq25to3un7f7iyh45tfxenmhj7vb3vwqd52i3@434do3lfdzq4>
References: <20231009153427.20951-1-brgl@bgdev.pl>
 <20231009153427.20951-14-brgl@bgdev.pl>
 <fr4jwbacvcheqtxy6php2u6wr72mqm5hgat6xwmxhijee7j6sk@azlu42eod6b4>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fr4jwbacvcheqtxy6php2u6wr72mqm5hgat6xwmxhijee7j6sk@azlu42eod6b4>
Precedence: bulk

On Wed, Oct 11, 2023 at 04:14:32PM -0500, Andrew Halaney wrote:
> On Mon, Oct 09, 2023 at 05:34:25PM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > 
> > Add a new Kconfig option for selecting the SHM Bridge mode of operation
> > for the TrustZone memory allocator.
> > 
> > If enabled at build-time, it will still be checked for availability at
> > run-time. If the architecture doesn't support SHM Bridge, the allocator
> > will work just like in the default mode.
> > 
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > ---
> >  drivers/firmware/qcom/Kconfig      | 10 +++++
> >  drivers/firmware/qcom/qcom_tzmem.c | 67 +++++++++++++++++++++++++++++-
> >  2 files changed, 76 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
> > index 237da40de832..e01407e31ae4 100644
> > --- a/drivers/firmware/qcom/Kconfig
> > +++ b/drivers/firmware/qcom/Kconfig
> > @@ -27,6 +27,16 @@ config QCOM_TZMEM_MODE_DEFAULT
> >  	  Use the default allocator mode. The memory is page-aligned, non-cachable
> >  	  and contiguous.
> >  
> > +config QCOM_TZMEM_MODE_SHMBRIDGE
> > +	bool "SHM Bridge"
> > +	help
> > +	  Use Qualcomm Shared Memory Bridge. The memory has the same alignment as
> > +	  in the 'Default' allocator but is also explicitly marked as an SHM Bridge
> > +	  buffer.
> > +
> > +	  With this selected, all buffers passed to the TrustZone must be allocated
> > +	  using the TZMem allocator or else the TrustZone will refuse to use them.
> > +
> >  endchoice
> >  
> >  config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
> > diff --git a/drivers/firmware/qcom/qcom_tzmem.c b/drivers/firmware/qcom/qcom_tzmem.c
> > index eee51fed756e..b3137844fe43 100644
> > --- a/drivers/firmware/qcom/qcom_tzmem.c
> > +++ b/drivers/firmware/qcom/qcom_tzmem.c
> > @@ -55,7 +55,72 @@ static void qcom_tzmem_cleanup_pool(struct qcom_tzmem_pool *pool)
> >  
> >  }
> >  
> > -#endif /* CONFIG_QCOM_TZMEM_MODE_DEFAULT */
> > +#elif IS_ENABLED(CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE)
> > +
> > +#include <linux/firmware/qcom/qcom_scm.h>
> > +
> > +#define QCOM_SHM_BRIDGE_NUM_VM_SHIFT 9
> > +
> > +static bool qcom_tzmem_using_shm_bridge;
> > +
> > +static int qcom_tzmem_init(void)
> > +{
> > +	int ret;
> > +
> > +	ret = qcom_scm_shm_bridge_enable();
> > +	if (ret == -EOPNOTSUPP) {
> > +		dev_info(qcom_tzmem_dev, "SHM Bridge not supported\n");
> > +		ret = 0;
> > +	}
> > +
> > +	if (!ret)
> > +		qcom_tzmem_using_shm_bridge = true;
> 
> Does the qcom_scm_shm_bridge_enable() returning -EOPNOTSUPP case make
> sense? Setting ret to 0 and then claiming we're using shm_bridge seems
> wrong to me.
> 
> > +
> > +	return ret;
> > +}
> > +
> > +static int qcom_tzmem_init_pool(struct qcom_tzmem_pool *pool)
> > +{
> > +	u64 pfn_and_ns_perm, ipfn_and_s_perm, size_and_flags, ns_perms, *handle;
> > +	int ret;
> > +
> > +	if (!qcom_tzmem_using_shm_bridge)
> > +		return 0;
> > +
> > +	ns_perms = (QCOM_SCM_PERM_WRITE | QCOM_SCM_PERM_READ);
> > +	pfn_and_ns_perm = (u64)pool->pbase | ns_perms;
> > +	ipfn_and_s_perm = (u64)pool->pbase | ns_perms;
> > +	size_and_flags = pool->size | (1 << QCOM_SHM_BRIDGE_NUM_VM_SHIFT);
> 
> Is there any sanity checking that can be done here? I assume bits 0-11 are all
> flag fields (or at least unrelated to size which I assume at a minimum
> must be 4k aka bit 12).

I guess qcom_tzmem_pool_new's PAGE_ALIGN would make sure this is
probably ok for all future users, but I do think some sanity would be
nice to indicate the size's allowed for SHM bridge.

> 
> > +
> > +	handle = kzalloc(sizeof(*handle), GFP_KERNEL);
> 
> Consider __free(kfree) + return_ptr() usage?
> 
> > +	if (!handle)
> > +		return -ENOMEM;
> > +
> > +	ret = qcom_scm_shm_bridge_create(qcom_tzmem_dev, pfn_and_ns_perm,
> > +					 ipfn_and_s_perm, size_and_flags,
> > +					 QCOM_SCM_VMID_HLOS, handle);
> > +	if (ret) {
> > +		kfree(handle);
> > +		return ret;
> > +	}
> > +
> > +	pool->priv = handle;
> > +
> > +	return 0;
> > +}
> > +
> > +static void qcom_tzmem_cleanup_pool(struct qcom_tzmem_pool *pool)
> > +{
> > +	u64 *handle = pool->priv;
> > +
> > +	if (!qcom_tzmem_using_shm_bridge)
> > +		return;
> > +
> > +	qcom_scm_shm_bridge_delete(qcom_tzmem_dev, *handle);
> > +	kfree(handle);
> > +}
> > +
> > +#endif /* CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE */
> >  
> >  /**
> >   * qcom_tzmem_pool_new() - Create a new TZ memory pool.
> > -- 
> > 2.39.2
> >