Message ID | 20231127141600.20929-1-brgl@bgdev.pl |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce62:0:b0:403:3b70:6f57 with SMTP id o2csp3152424vqx; Mon, 27 Nov 2023 06:19:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IECU3dnDBhYyXScYuT2MspsnTz8fuFCoJ1Knd+L+WzpOYEpcHYBKSInVs/mPu6P3gYLCbXY X-Received: by 2002:a05:6a00:14c6:b0:6c4:dc5b:5b2b with SMTP id w6-20020a056a0014c600b006c4dc5b5b2bmr12369674pfu.20.1701094758936; Mon, 27 Nov 2023 06:19:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701094758; cv=none; d=google.com; s=arc-20160816; b=c04eM49wVTSHMWK4LFzIwrQNQwzG9q2vt/2+PXG689qJg3al9XVx9hb+JJxNI20Duy Bd3pv7y+NNUFjuQG1eI4l0rP1UArcy4g8iYRv+GtDGDxGm/YWbSwEUCFZZKZtstgu46T daV6u02aB45pPOJ5TiFMn+P1Uig/cZxp1q6qXUlUZWicVNkoqm/Y9udEMNWguWwx/2BP 4bV5bGxlhOBOi/0M6gwPgVKXyWxmNeAvwQJbBScCRK91LE+4u04DQvQ9hxM7xMQWaMSb 9OOIcn1k+4q/OgyNNpMUhQtHjaTbnZ7bxWdS3koOlQa1smz4Zj+YwLYShHLY17StCIV8 oQSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=tDfBn/A7cOmjON95tH3n6IWAPDyFmsYlwqjQ+7NABPM=; fh=lirm1ccAeXZZB1cIo+N1DqklpgcFmD/vJ7PCWNIL0HU=; b=fYoQ6Yt4k3YmP8a2kdrB8QIAF2lx9lp5lMFiBtpahDuKjionOuTuQU4I7oPW7z0nn6 reGGwKtdLobFh7IV8RQBKK0mmcGlKiKuOf2Xqc4UwJJ5Ssk8W/Pef0yytRBqnwNe4li9 NJOQhpx/9kyYVGPnIHrTOKpp6CAZ5+flZIQd5cZISXwH/UejnMFPPSTWdxIwcA89z7Rq 2UscAiitOdI43chtzqtJ/0HdWZK0ca5ueDr7KmLwH4KsKPjRRXU99q5VUSFNSmmj16nZ jXL2TONb3TNVN+Tgc/bmj4FGpENm0bL/oUPWJqx7kjiip0DQe/x5d1nXcxuBKmZPa0eI kO5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=2ucWUxCS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id p4-20020a056a000b4400b006cd94e0c112si1200040pfo.285.2023.11.27.06.19.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Nov 2023 06:19:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=2ucWUxCS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id C124D805BC9D; Mon, 27 Nov 2023 06:19:17 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233570AbjK0OTF (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Mon, 27 Nov 2023 09:19:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233615AbjK0OSo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 27 Nov 2023 09:18:44 -0500 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE5F83A9D for <linux-kernel@vger.kernel.org>; Mon, 27 Nov 2023 06:16:10 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-40838915cecso29763545e9.2 for <linux-kernel@vger.kernel.org>; Mon, 27 Nov 2023 06:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20230601.gappssmtp.com; s=20230601; t=1701094569; x=1701699369; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=tDfBn/A7cOmjON95tH3n6IWAPDyFmsYlwqjQ+7NABPM=; b=2ucWUxCS7CfX+aurKOXtOSlawg+FCckslImZMbaMwVa9cmZIgP3TasMtYZ5b0sejpp melyyy6E986mEBeHY0OCgYYgh7/bHQc0DMIBzIuahHhdTqcAYMjYMpJRz5nyeE3CM+U/ 6nXS/ddMqTxzb0aJlpOTfgdAPaTlHgDnL5Hb/i+IYEH8WrE5cZXZa1KwWlIE7fnVl64h ojEDBOldq6LJH+xoF9lW4omA5CjE0KMZWJUvW3J9rcHwlvI9zNmOBrAP9TPTZpbu18mN WCjIk0OUVBe2AHH9T9NzfbUevYen1NU225Spiu1MbEXsUlJ/dj+TYsb+91Y6JT6ua4Zf lm7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701094569; x=1701699369; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tDfBn/A7cOmjON95tH3n6IWAPDyFmsYlwqjQ+7NABPM=; b=wbSyub71Qn1syqs3k0eoU5VCt1u1O9M75xbren5jCJs/KoQz/tcIAQSmomIdaw9dG8 UnKlVp9jlDnQFYDd/Xp9W+G9eWyY/gQ+ecKAmFCQJxYuPI/57CJIseiFzZXNprC38fv1 ndQaVL3kEfBhtC+1ThKcTDCtTNPIsMfg3uOWCMM78lN30DRHg9ZnjWVaUJjkBPXUbHsX UszAfndrxmN7Gkyh2namoYO1/sSQpf2bfzp5dOkRWjgXZrNygTmhqI4tSh/X3RU50/1K 21Kg8yn3gY5l0cC42yDcCPl6a0zhSlSLvPBNDaVnkHLN6G4FUJKGF7PVUdn4lLWXrfrS a98Q== X-Gm-Message-State: AOJu0YwMV13Hr5NnMgQ1teOLbtlduMJD2LwKxl9jmt0KDSjXCL7/eXAE ZCZ+hu2fx+QIJ/fkqkXAXr675Q== X-Received: by 2002:a05:600c:35d5:b0:401:bcd9:4871 with SMTP id r21-20020a05600c35d500b00401bcd94871mr5182402wmq.21.1701094568325; Mon, 27 Nov 2023 06:16:08 -0800 (PST) Received: from brgl-uxlite.home ([2a01:cb1d:334:ac00:bf33:77c7:8131:5e64]) by smtp.gmail.com with ESMTPSA id be7-20020a05600c1e8700b00405442edc69sm14658830wmb.14.2023.11.27.06.16.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Nov 2023 06:16:07 -0800 (PST) From: Bartosz Golaszewski <brgl@bgdev.pl> To: 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>, Andrew Halaney <ahalaney@redhat.com>, Maximilian Luz <luzmaximilian@gmail.com>, Alex Elder <elder@linaro.org>, Srini Kandagatla <srinivas.kandagatla@linaro.org> Cc: 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: [PATCH v6 00/13] arm64: qcom: add and enable SHM Bridge support Date: Mon, 27 Nov 2023 15:15:47 +0100 Message-Id: <20231127141600.20929-1-brgl@bgdev.pl> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 27 Nov 2023 06:19:18 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783727138105270815 X-GMAIL-MSGID: 1783727138105270815 |
Series |
arm64: qcom: add and enable SHM Bridge support
|
|
Message
Bartosz Golaszewski
Nov. 27, 2023, 2:15 p.m. UTC
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This is pretty much another full rewrite of the SHM Bridge support
series. After more on- and off-list discussions I think this time it
will be close to the final thing though.
We've established the need for using separate pools for SCM and QSEECOM
as well as the upcoming scminvoke driver.
It's also become clear that in order to be future-proof, the new
allocator must be an abstraction layer of a higher level as the SHM
Bridge will not be the only memory protection mechanism that we'll see
upstream. Hence the rename to TrustZone Memory rather than SCM Memory
allocator.
Also to that end: the new allocator is its own module now and provides a
Kconfig choice menu for selecting the mode of operation (currently
default and SHM Bridge).
Due to a high divergence from v2, I dropped all tags except for
patch 1/15 which didn't change.
Tested on sm8550 and sa8775p with the Inline Crypto Engine and
remoteproc.
v5 -> v6:
Fixed two issues reported by autobuilders:
- add a fix for memory leaks in the qseecom driver as the first patch for
easier backporting to the v6.6.y branch
- explicitly cast the bus address stored in a variable of type dma_addr_t
to phys_addr_t expected by the genpool API
v4 -> v5:
- fix the return value from qcom_tzmem_init() if SHM Bridge is not supported
- remove a comment that's no longer useful
- collect tags
v3 -> v4:
- include linux/sizes.h for SZ_X macros
- use dedicated RCU APIs to dereference radix tree slots
- fix kerneldocs
- fix the comment in patch 14/15: it's the hypervisor, not the TrustZone
that creates the SHM bridge
v2 -> v3:
- restore pool management and use separate pools for different users
- don't use the new allocator in qcom_scm_pas_init_image() as the
TrustZone will create an SHM bridge for us here
- rewrite the entire series again for most part
v1 -> v2:
- too many changes to list, it's a complete rewrite as explained above
Bartosz Golaszewski (13):
firmware: qcom: qseecom: fix memory leaks in error paths
firmware: qcom: add a dedicated TrustZone buffer allocator
firmware: qcom: scm: enable the TZ mem allocator
firmware: qcom: scm: smc: switch to using the SCM allocator
firmware: qcom: scm: make qcom_scm_assign_mem() use the TZ allocator
firmware: qcom: scm: make qcom_scm_ice_set_key() use the TZ allocator
firmware: qcom: scm: make qcom_scm_lmh_dcvsh() use the TZ allocator
firmware: qcom: scm: make qcom_scm_qseecom_app_get_id() use the TZ
allocator
firmware: qcom: qseecom: convert to using the TZ allocator
firmware: qcom: scm: add support for SHM bridge operations
firmware: qcom: tzmem: enable SHM Bridge support
firmware: qcom: scm: clarify the comment in qcom_scm_pas_init_image()
arm64: defconfig: enable SHM Bridge support for the TZ memory
allocator
arch/arm64/configs/defconfig | 1 +
drivers/firmware/qcom/Kconfig | 30 ++
drivers/firmware/qcom/Makefile | 1 +
.../firmware/qcom/qcom_qseecom_uefisecapp.c | 261 +++++--------
drivers/firmware/qcom/qcom_scm-smc.c | 30 +-
drivers/firmware/qcom/qcom_scm.c | 179 +++++----
drivers/firmware/qcom/qcom_scm.h | 6 +
drivers/firmware/qcom/qcom_tzmem.c | 365 ++++++++++++++++++
drivers/firmware/qcom/qcom_tzmem.h | 13 +
include/linux/firmware/qcom/qcom_qseecom.h | 4 +-
include/linux/firmware/qcom/qcom_scm.h | 6 +
include/linux/firmware/qcom/qcom_tzmem.h | 28 ++
12 files changed, 669 insertions(+), 255 deletions(-)
create mode 100644 drivers/firmware/qcom/qcom_tzmem.c
create mode 100644 drivers/firmware/qcom/qcom_tzmem.h
create mode 100644 include/linux/firmware/qcom/qcom_tzmem.h
Comments
On 11/27/2023 6:15 AM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > This is pretty much another full rewrite of the SHM Bridge support > series. After more on- and off-list discussions I think this time it > will be close to the final thing though. > > We've established the need for using separate pools for SCM and QSEECOM > as well as the upcoming scminvoke driver. > > It's also become clear that in order to be future-proof, the new > allocator must be an abstraction layer of a higher level as the SHM > Bridge will not be the only memory protection mechanism that we'll see > upstream. Hence the rename to TrustZone Memory rather than SCM Memory > allocator. > > Also to that end: the new allocator is its own module now and provides a > Kconfig choice menu for selecting the mode of operation (currently > default and SHM Bridge). > > Due to a high divergence from v2, I dropped all tags except for > patch 1/15 which didn't change. > > Tested on sm8550 and sa8775p with the Inline Crypto Engine and > remoteproc. > > v5 -> v6: > Fixed two issues reported by autobuilders: > - add a fix for memory leaks in the qseecom driver as the first patch for > easier backporting to the v6.6.y branch > - explicitly cast the bus address stored in a variable of type dma_addr_t > to phys_addr_t expected by the genpool API > > v4 -> v5: > - fix the return value from qcom_tzmem_init() if SHM Bridge is not supported > - remove a comment that's no longer useful > - collect tags > > v3 -> v4: > - include linux/sizes.h for SZ_X macros > - use dedicated RCU APIs to dereference radix tree slots > - fix kerneldocs > - fix the comment in patch 14/15: it's the hypervisor, not the TrustZone > that creates the SHM bridge > > v2 -> v3: > - restore pool management and use separate pools for different users > - don't use the new allocator in qcom_scm_pas_init_image() as the > TrustZone will create an SHM bridge for us here > - rewrite the entire series again for most part > > v1 -> v2: > - too many changes to list, it's a complete rewrite as explained above > > Bartosz Golaszewski (13): > firmware: qcom: qseecom: fix memory leaks in error paths > firmware: qcom: add a dedicated TrustZone buffer allocator > firmware: qcom: scm: enable the TZ mem allocator > firmware: qcom: scm: smc: switch to using the SCM allocator > firmware: qcom: scm: make qcom_scm_assign_mem() use the TZ allocator > firmware: qcom: scm: make qcom_scm_ice_set_key() use the TZ allocator > firmware: qcom: scm: make qcom_scm_lmh_dcvsh() use the TZ allocator > firmware: qcom: scm: make qcom_scm_qseecom_app_get_id() use the TZ > allocator > firmware: qcom: qseecom: convert to using the TZ allocator > firmware: qcom: scm: add support for SHM bridge operations > firmware: qcom: tzmem: enable SHM Bridge support > firmware: qcom: scm: clarify the comment in qcom_scm_pas_init_image() > arm64: defconfig: enable SHM Bridge support for the TZ memory > allocator > > arch/arm64/configs/defconfig | 1 + > drivers/firmware/qcom/Kconfig | 30 ++ > drivers/firmware/qcom/Makefile | 1 + > .../firmware/qcom/qcom_qseecom_uefisecapp.c | 261 +++++-------- > drivers/firmware/qcom/qcom_scm-smc.c | 30 +- > drivers/firmware/qcom/qcom_scm.c | 179 +++++---- > drivers/firmware/qcom/qcom_scm.h | 6 + > drivers/firmware/qcom/qcom_tzmem.c | 365 ++++++++++++++++++ > drivers/firmware/qcom/qcom_tzmem.h | 13 + > include/linux/firmware/qcom/qcom_qseecom.h | 4 +- > include/linux/firmware/qcom/qcom_scm.h | 6 + > include/linux/firmware/qcom/qcom_tzmem.h | 28 ++ > 12 files changed, 669 insertions(+), 255 deletions(-) > create mode 100644 drivers/firmware/qcom/qcom_tzmem.c > create mode 100644 drivers/firmware/qcom/qcom_tzmem.h > create mode 100644 include/linux/firmware/qcom/qcom_tzmem.h > Verified the following : Shm Bridge creation Successful qcom_scm_assign_mem calls using tz allocator Tested-by: Deepti Jaggi <quic_djaggi@quicinc.com> #sa8775p-ride
On Mon, 27 Nov 2023 15:15:47 +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > This is pretty much another full rewrite of the SHM Bridge support > series. After more on- and off-list discussions I think this time it > will be close to the final thing though. > > We've established the need for using separate pools for SCM and QSEECOM > as well as the upcoming scminvoke driver. > > [...] Applied, thanks! [01/13] firmware: qcom: qseecom: fix memory leaks in error paths commit: 6c57d7b593c4a4e60db65d5ce0fe1d9f79ccbe9b Best regards,
On 11/27/2023 6:15 AM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > This is pretty much another full rewrite of the SHM Bridge support > series. After more on- and off-list discussions I think this time it > will be close to the final thing though. > > We've established the need for using separate pools for SCM and QSEECOM > as well as the upcoming scminvoke driver. > > It's also become clear that in order to be future-proof, the new > allocator must be an abstraction layer of a higher level as the SHM > Bridge will not be the only memory protection mechanism that we'll see > upstream. Hence the rename to TrustZone Memory rather than SCM Memory > allocator. > > Also to that end: the new allocator is its own module now and provides a > Kconfig choice menu for selecting the mode of operation (currently > default and SHM Bridge). > > Due to a high divergence from v2, I dropped all tags except for > patch 1/15 which didn't change. > > Tested on sm8550 and sa8775p with the Inline Crypto Engine and > remoteproc. > > v5 -> v6: > Fixed two issues reported by autobuilders: > - add a fix for memory leaks in the qseecom driver as the first patch for > easier backporting to the v6.6.y branch > - explicitly cast the bus address stored in a variable of type dma_addr_t > to phys_addr_t expected by the genpool API > > v4 -> v5: > - fix the return value from qcom_tzmem_init() if SHM Bridge is not supported > - remove a comment that's no longer useful > - collect tags > > v3 -> v4: > - include linux/sizes.h for SZ_X macros > - use dedicated RCU APIs to dereference radix tree slots > - fix kerneldocs > - fix the comment in patch 14/15: it's the hypervisor, not the TrustZone > that creates the SHM bridge > > v2 -> v3: > - restore pool management and use separate pools for different users > - don't use the new allocator in qcom_scm_pas_init_image() as the > TrustZone will create an SHM bridge for us here > - rewrite the entire series again for most part > > v1 -> v2: > - too many changes to list, it's a complete rewrite as explained above > > Bartosz Golaszewski (13): > firmware: qcom: qseecom: fix memory leaks in error paths > firmware: qcom: add a dedicated TrustZone buffer allocator > firmware: qcom: scm: enable the TZ mem allocator > firmware: qcom: scm: smc: switch to using the SCM allocator > firmware: qcom: scm: make qcom_scm_assign_mem() use the TZ allocator > firmware: qcom: scm: make qcom_scm_ice_set_key() use the TZ allocator > firmware: qcom: scm: make qcom_scm_lmh_dcvsh() use the TZ allocator > firmware: qcom: scm: make qcom_scm_qseecom_app_get_id() use the TZ > allocator > firmware: qcom: qseecom: convert to using the TZ allocator > firmware: qcom: scm: add support for SHM bridge operations > firmware: qcom: tzmem: enable SHM Bridge support > firmware: qcom: scm: clarify the comment in qcom_scm_pas_init_image() > arm64: defconfig: enable SHM Bridge support for the TZ memory > allocator > > arch/arm64/configs/defconfig | 1 + > drivers/firmware/qcom/Kconfig | 30 ++ > drivers/firmware/qcom/Makefile | 1 + > .../firmware/qcom/qcom_qseecom_uefisecapp.c | 261 +++++-------- > drivers/firmware/qcom/qcom_scm-smc.c | 30 +- > drivers/firmware/qcom/qcom_scm.c | 179 +++++---- > drivers/firmware/qcom/qcom_scm.h | 6 + > drivers/firmware/qcom/qcom_tzmem.c | 365 ++++++++++++++++++ > drivers/firmware/qcom/qcom_tzmem.h | 13 + > include/linux/firmware/qcom/qcom_qseecom.h | 4 +- > include/linux/firmware/qcom/qcom_scm.h | 6 + > include/linux/firmware/qcom/qcom_tzmem.h | 28 ++ > 12 files changed, 669 insertions(+), 255 deletions(-) > create mode 100644 drivers/firmware/qcom/qcom_tzmem.c > create mode 100644 drivers/firmware/qcom/qcom_tzmem.h > create mode 100644 include/linux/firmware/qcom/qcom_tzmem.h > Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>