Message ID | 20231013114843.63205-1-brgl@bgdev.pl |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp1829819vqb; Fri, 13 Oct 2023 04:49:13 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFTmF4NgdizNsVcwuDK5mWMtZJIRtZWAEAVNFDfkfabva2cydLZM2alfi5JACmVAl3lyqLz X-Received: by 2002:a05:6830:6685:b0:6b1:9646:2ea0 with SMTP id cq5-20020a056830668500b006b196462ea0mr35987420otb.1.1697197753257; Fri, 13 Oct 2023 04:49:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697197753; cv=none; d=google.com; s=arc-20160816; b=hZF7ejimb9HZE/RYMSyrOA28r+qlib3heAArVlDKHXkrT7p1tRP3PSB1tsdYu8/KJv gkyOf6matI5jn7AhDIv7EcvCsx3GIfNtBTIleTePNCT6q4BwSPwXRBx4vD2ZI5dwPb+o Q1K2zls5UTHVum9DQNgGp663jyMWndOUTgnyaTOol+YSD1Pz8IDKHDmvDj5x9TKckYZE urai86jI59OJqbI5D+vGzOczikpoOczm/z/LDpPn/dTlaz7+NxS1gIeMqI2ossO/Xguo kuFYSPhqZQJZaFK5+rrGKMjb5stDUF8FQNyU3F6IaWEL6knrR+YkY5yCAWUt91Dc2jHG W0ug== 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=2gi1dKzgbLyY2SGQKC/6ay+pgQCsg2LD4vhB0IMddqs=; fh=lirm1ccAeXZZB1cIo+N1DqklpgcFmD/vJ7PCWNIL0HU=; b=wpK9Kao6w2awWCCLBYGNgkpFwZPqqhXFFbKsYLaiqNVqEy4dDuNT+Pbqr3Jp+cczuO rumNEzNGxjQfLe6Dk4rX6rgHofP6m7I1Egfuup4pPatwoRcpt80iDFySGq+XKnZ4NQIi p4owvIhjyChcCS/NuZ4jBEeSgLDSGEHj8ujZRJM8y3m0mXVioKAPHw1x1kX0zcSBqjla ru8+KisyVOoq3u2dS/aX4Ugkib5RbJcAsK21/ouAUFL5P1682Cydl7E3JKY9mhmVocxD Gisz68KszkKCJYEeMdxInM5FUKLmDodlq6qvuCfymQ1w1Ejombb7WKSBJfVEtKRA4NMQ 0cZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=Df+x9qIr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id a13-20020a056a000c8d00b0068e256c6366si16921907pfv.352.2023.10.13.04.49.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Oct 2023 04:49:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=Df+x9qIr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 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 morse.vger.email (Postfix) with ESMTP id B627083B64ED; Fri, 13 Oct 2023 04:49:10 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230458AbjJMLtA (ORCPT <rfc822;rua109.linux@gmail.com> + 19 others); Fri, 13 Oct 2023 07:49:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231410AbjJMLs4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 13 Oct 2023 07:48:56 -0400 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FD95B7 for <linux-kernel@vger.kernel.org>; Fri, 13 Oct 2023 04:48:54 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-31f71b25a99so1881428f8f.2 for <linux-kernel@vger.kernel.org>; Fri, 13 Oct 2023 04:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20230601.gappssmtp.com; s=20230601; t=1697197733; x=1697802533; 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=2gi1dKzgbLyY2SGQKC/6ay+pgQCsg2LD4vhB0IMddqs=; b=Df+x9qIrKOtgMBqVwf8EslOGU+zId7IHjzs4pYWovq3Q1n8gohvzjJuFyEOJNNL0VQ G9xymbxKoiLlOJwwjN3EJ5is5Mha6/b9JkXxm7kKD1fJ08BAaQqmU9Tvxeyp47DrT+2T Tn+rKI5zQIsf5bnLulL2/qgr5KshrP3uyr53uDZcej3yDPNJ+i4xerYZgCq/z4zhbbIs A/bVsSUEZkk/6ZN16TAPotudhvEg4pkHxaSegP7X/SwHrOSzJVnoF4k0Fgo7ezOLJdGe P6eq9vIEWCpxszVx/XSB2/HGeT0O84BaYwFKQDTF0o34TzVma8Py1Zd11EAyw83DPDOh bMCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697197733; x=1697802533; 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=2gi1dKzgbLyY2SGQKC/6ay+pgQCsg2LD4vhB0IMddqs=; b=uqKjzSOhFNbC5J0bKQsUmj4mBuIaceYBjtkGdSZ8uv+91+uYy06R8Ih04YGW3upgUS zQa/K6jUYrEVg55LhOtGtWbjuXHHUMuwqEEn7KfyTvcFmJeniEFRvjBYxrmHZq4lYona M0QqP3SsslMcv3++EOjC7VkhBzBS4tgxwR9tH5gdFNrylUDGA/9c60/wbp4EJrfHFvwq oOb4wJPHF+y1365KeLaLYzBklgR3xQKJEJ0mijQS8QApja6UNjUYuZPA1RwEgh0umP2N 8KgzqC02XWQV0R7eR2S5Q3gGln4vyXZFWlM1/fbkdZkr14zuzPEiKePx9HyhyzgU4qow NfWQ== X-Gm-Message-State: AOJu0Yzi1rmXE0vcC/nJ2axzlqhWINrPOOZeoY3Am9CnS8+nIkUI4KMA rwaF/H1Cf7Htx/hDxxSYiB453Q== X-Received: by 2002:adf:f28b:0:b0:321:67f4:8bd7 with SMTP id k11-20020adff28b000000b0032167f48bd7mr22133317wro.32.1697197732611; Fri, 13 Oct 2023 04:48:52 -0700 (PDT) Received: from brgl-uxlite.home ([2a01:cb1d:334:ac00:4209:13a:988d:80be]) by smtp.gmail.com with ESMTPSA id j23-20020a05600c1c1700b00407754b998dsm974509wms.27.2023.10.13.04.48.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Oct 2023 04:48:52 -0700 (PDT) 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 v4 00/15] arm64: qcom: add and enable SHM Bridge support Date: Fri, 13 Oct 2023 13:48:28 +0200 Message-Id: <20231013114843.63205-1-brgl@bgdev.pl> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email 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 (morse.vger.email [0.0.0.0]); Fri, 13 Oct 2023 04:49:10 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779640831305059455 X-GMAIL-MSGID: 1779640831305059455 |
Series |
arm64: qcom: add and enable SHM Bridge support
|
|
Message
Bartosz Golaszewski
Oct. 13, 2023, 11:48 a.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.
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 (15):
firmware: qcom: move Qualcomm code into its own directory
firmware: qcom: scm: add a missing forward declaration for struct
device
firmware: qcom: scm: remove unneeded 'extern' specifiers
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
MAINTAINERS | 4 +-
arch/arm64/configs/defconfig | 1 +
drivers/firmware/Kconfig | 48 +--
drivers/firmware/Makefile | 5 +-
drivers/firmware/qcom/Kconfig | 86 +++++
drivers/firmware/qcom/Makefile | 10 +
drivers/firmware/{ => qcom}/qcom_qseecom.c | 0
.../{ => qcom}/qcom_qseecom_uefisecapp.c | 261 +++++--------
drivers/firmware/{ => qcom}/qcom_scm-legacy.c | 0
drivers/firmware/{ => qcom}/qcom_scm-smc.c | 28 +-
drivers/firmware/{ => qcom}/qcom_scm.c | 179 +++++----
drivers/firmware/{ => qcom}/qcom_scm.h | 21 +-
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 ++
17 files changed, 746 insertions(+), 313 deletions(-)
create mode 100644 drivers/firmware/qcom/Kconfig
create mode 100644 drivers/firmware/qcom/Makefile
rename drivers/firmware/{ => qcom}/qcom_qseecom.c (100%)
rename drivers/firmware/{ => qcom}/qcom_qseecom_uefisecapp.c (84%)
rename drivers/firmware/{ => qcom}/qcom_scm-legacy.c (100%)
rename drivers/firmware/{ => qcom}/qcom_scm-smc.c (91%)
rename drivers/firmware/{ => qcom}/qcom_scm.c (93%)
rename drivers/firmware/{ => qcom}/qcom_scm.h (88%)
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 Fri, Oct 13, 2023 at 01:48:28PM +0200, 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. I took this for a spin on my x13s with SHM bridge enabled and don't see any issues in the usecases that exercises. Also running on a debug kernel with no warnings, etc. Tested-by: Andrew Halaney <ahalaney@redhat.com> # sc8280xp-lenovo-thinkpad-x13s > > 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 (15): > firmware: qcom: move Qualcomm code into its own directory > firmware: qcom: scm: add a missing forward declaration for struct > device > firmware: qcom: scm: remove unneeded 'extern' specifiers > 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 > > MAINTAINERS | 4 +- > arch/arm64/configs/defconfig | 1 + > drivers/firmware/Kconfig | 48 +-- > drivers/firmware/Makefile | 5 +- > drivers/firmware/qcom/Kconfig | 86 +++++ > drivers/firmware/qcom/Makefile | 10 + > drivers/firmware/{ => qcom}/qcom_qseecom.c | 0 > .../{ => qcom}/qcom_qseecom_uefisecapp.c | 261 +++++-------- > drivers/firmware/{ => qcom}/qcom_scm-legacy.c | 0 > drivers/firmware/{ => qcom}/qcom_scm-smc.c | 28 +- > drivers/firmware/{ => qcom}/qcom_scm.c | 179 +++++---- > drivers/firmware/{ => qcom}/qcom_scm.h | 21 +- > 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 ++ > 17 files changed, 746 insertions(+), 313 deletions(-) > create mode 100644 drivers/firmware/qcom/Kconfig > create mode 100644 drivers/firmware/qcom/Makefile > rename drivers/firmware/{ => qcom}/qcom_qseecom.c (100%) > rename drivers/firmware/{ => qcom}/qcom_qseecom_uefisecapp.c (84%) > rename drivers/firmware/{ => qcom}/qcom_scm-legacy.c (100%) > rename drivers/firmware/{ => qcom}/qcom_scm-smc.c (91%) > rename drivers/firmware/{ => qcom}/qcom_scm.c (93%) > rename drivers/firmware/{ => qcom}/qcom_scm.h (88%) > 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 > > -- > 2.39.2 >