| Message ID | 20240205182810.58382-12-brgl@bgdev.pl |
|---|---|
| State | New |
| Headers | show |
| Series | [v7,01/12] firmware: qcom: add a dedicated TrustZone buffer allocator | expand |
On Mon, Feb 05, 2024 at 07:28:09PM +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > The "memory protection" mechanism mentioned in the comment is the SHM > Bridge. This is also the reason why we do not convert this call to using > the TZ memory allocator. > No, this mechanism predates shmbridge. > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s > Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride > Reviewed-by: Elliot Berman <quic_eberman@quicinc.com> > --- > drivers/firmware/qcom/qcom_scm.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c > index 839773270a21..7ba5cff6e4e7 100644 > --- a/drivers/firmware/qcom/qcom_scm.c > +++ b/drivers/firmware/qcom/qcom_scm.c > @@ -563,9 +563,13 @@ int qcom_scm_pas_init_image(u32 peripheral, const void *metadata, size_t size, > struct qcom_scm_res res; > > /* > - * During the scm call memory protection will be enabled for the meta > - * data blob, so make sure it's physically contiguous, 4K aligned and > - * non-cachable to avoid XPU violations. What this is saying is that the memory will be made unaccessible to Linux, so it needs to be contiguous and aligned. > + * During the SCM call the hypervisor will make the buffer containing > + * the program data into an SHM Bridge. Are you saying that the hypervisor will convert this memory to a shmbridge, and then pass it to TrustZone? > This is why we exceptionally > + * must not use the TrustZone memory allocator here as - depending on > + * Kconfig - it may already use the SHM Bridge mechanism internally. > + * "it may already"? You describe above that we shouldn't pass shmbridge memory, and the other case never deals with shmbridges. So, I think you can omit this part. > + * If we pass a buffer that is already part of an SHM Bridge to this > + * call, it will fail. Could this be because the consumer of this buffer operates in EL2, and not TZ? Regards, Bjorn > */ > mdata_buf = dma_alloc_coherent(__scm->dev, size, &mdata_phys, > GFP_KERNEL); > -- > 2.40.1 >
diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c index 839773270a21..7ba5cff6e4e7 100644 --- a/drivers/firmware/qcom/qcom_scm.c +++ b/drivers/firmware/qcom/qcom_scm.c @@ -563,9 +563,13 @@ int qcom_scm_pas_init_image(u32 peripheral, const void *metadata, size_t size, struct qcom_scm_res res; /* - * During the scm call memory protection will be enabled for the meta - * data blob, so make sure it's physically contiguous, 4K aligned and - * non-cachable to avoid XPU violations. + * During the SCM call the hypervisor will make the buffer containing + * the program data into an SHM Bridge. This is why we exceptionally + * must not use the TrustZone memory allocator here as - depending on + * Kconfig - it may already use the SHM Bridge mechanism internally. + * + * If we pass a buffer that is already part of an SHM Bridge to this + * call, it will fail. */ mdata_buf = dma_alloc_coherent(__scm->dev, size, &mdata_phys, GFP_KERNEL);