From: Mukesh Ojha <quic_mojha@quicinc.com>
To: Bjorn Andersson <andersson@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Rob Herring <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
"Konrad Dybcio" <konradybcio@kernel.org>,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: <linux-arm-msm@vger.kernel.org>,
<linux-remoteproc@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Mukesh Ojha <quic_mojha@quicinc.com>
Subject: [PATCH 0/6] Peripheral Image Loader support for Qualcomm SoCs
Date: Sat, 5 Oct 2024 02:53:53 +0530 [thread overview]
Message-ID: <20241004212359.2263502-1-quic_mojha@quicinc.com> (raw)
Qualcomm is looking to enable remote processors on the SA8775p SoC
running KVM Linux host and is currently trying to figure out an
upstream-compatible solution for the IOMMU translation scheme problem it
is facing when SoCs running with KVM. This issue arises due to
differences in how IOMMU translation is currently handled on SoCs
running Qualcomm EL2 hypervisor(QHEE) where IOMMU translation for any
device is completely owned by it and the other issue is that remote
processors firmware does not contain resource table where these IOMMU
configuration setting will be present.
Qualcomm SoCs running with the QHEE(EL2) have been utilizing the
Peripheral Authentication Service (PAS) from its TrustZone (TZ) firmware
to securely authenticate and reset via a single SMC call
_auth_and_reset_. This call first gets trapped to QHEE, which then
makes a call to TZ for authentication. Once it is done, the call returns
to QHEE, which sets up the IOMMU translation scheme for these remote
processors and later brings them out of reset. The design of the
Qualcomm EL2 hypervisor dictates that the Linux host OS running at EL1
is not allowed to set up IOMMU translation for remote processors,
and only a single stage is being configured for them.
To make the remote processors’ bring-up (PAS) sequence
hypervisor-independent, the auth_and_reset SMC call is now entirely
handled by TZ. However, the problem of IOMMU handling still remains with
the KVM host, which has no knowledge of the remote processors’ IOMMU
configuration.
We have looked up one approach where SoC remoteproc device tree could
contain resources like iommus for remoteproc carveout and qcom,devmem
specific binding for device memory needed for remoteproc and these
properties are optional and will only be overlaid by the firmware if it
is running with non-QHEE based hypervisor like KVM.
- Patch 1/6 adds the iommus and qcom,devmem binding for PAS common yaml.
- Patch 2/6 and 3/6 add helper function to IOMMU map and unmap carveout
and device memory region.
- Patch 4/6 adds a function to parse individual field of qcom,devmem property.
- Patch 5/6 add helpers to create/destroy SHM bridge for remoteproc
carveout and to get memory from tzmem SHM bridge pool for remoteproc
firmware metadata.
- Patch 6/6 enable all the required support to enable remoteproc for
non-QHEE hypervisor based systems like KVM host via parsing the iommus
properties and mapping/unmapping carveout and device memory based on
it.
Komal Bajaj (1):
remoteproc: qcom: Add iommu map_unmap helper function
Mukesh Ojha (2):
remoteproc: qcom: Add support of SHM bridge to enable memory
protection
remoteproc: qcom: Enable map/unmap and SHM bridge support
Shiraz Hashim (3):
dt-bindings: remoteproc: qcom,pas-common: Introduce iommus and
qcom,devmem property
remoteproc: qcom: Add helper function to support IOMMU devmem
translation
remoteproc: qcom: Add support to parse qcom,devmem property
.../bindings/remoteproc/qcom,pas-common.yaml | 42 +++++
.../bindings/remoteproc/qcom,sa8775p-pas.yaml | 20 +++
drivers/firmware/qcom/qcom_scm.c | 29 +++-
drivers/firmware/qcom/qcom_tzmem.c | 14 +-
drivers/remoteproc/qcom_common.c | 148 ++++++++++++++++++
drivers/remoteproc/qcom_common.h | 38 +++++
drivers/remoteproc/qcom_q6v5_pas.c | 140 ++++++++++++++++-
include/linux/firmware/qcom/qcom_scm.h | 1 +
include/linux/firmware/qcom/qcom_tzmem.h | 10 ++
9 files changed, 423 insertions(+), 19 deletions(-)
--
2.34.1
next reply other threads:[~2024-10-04 21:24 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-04 21:23 Mukesh Ojha [this message]
2024-10-04 21:23 ` [PATCH 1/6] dt-bindings: remoteproc: qcom,pas-common: Introduce iommus and qcom,devmem property Mukesh Ojha
2024-10-06 19:38 ` Dmitry Baryshkov
2024-10-07 15:35 ` Mukesh Ojha
2024-10-07 16:25 ` Dmitry Baryshkov
2024-10-09 14:04 ` Shiraz Hashim
2024-10-10 7:15 ` Krzysztof Kozlowski
2024-10-10 8:30 ` Shiraz Hashim
2024-10-04 21:23 ` [PATCH 2/6] remoteproc: qcom: Add iommu map_unmap helper function Mukesh Ojha
2024-10-06 2:04 ` kernel test robot
2024-10-06 4:29 ` kernel test robot
2024-10-04 21:23 ` [PATCH 3/6] remoteproc: qcom: Add helper function to support IOMMU devmem translation Mukesh Ojha
2024-10-07 8:08 ` neil.armstrong
2024-10-07 14:37 ` Mukesh Ojha
2024-10-10 6:59 ` neil.armstrong
2024-10-17 21:25 ` Konrad Dybcio
2024-10-04 21:23 ` [PATCH 4/6] remoteproc: qcom: Add support to parse qcom,devmem property Mukesh Ojha
2024-10-04 21:23 ` [PATCH 5/6] remoteproc: qcom: Add support of SHM bridge to enable memory protection Mukesh Ojha
2024-10-05 22:26 ` kernel test robot
2024-10-25 19:03 ` Konrad Dybcio
2024-10-04 21:23 ` [PATCH 6/6] remoteproc: qcom: Enable map/unmap and SHM bridge support Mukesh Ojha
2024-10-07 8:05 ` neil.armstrong
2024-10-07 14:52 ` Mukesh Ojha
2024-10-08 6:21 ` Mukesh Ojha
2024-10-10 6:57 ` neil.armstrong
2024-10-11 5:05 ` Shiraz Hashim
2024-10-11 6:23 ` Dmitry Baryshkov
2024-10-11 7:09 ` Shiraz Hashim
2024-10-11 7:12 ` Dmitry Baryshkov
2024-10-14 12:31 ` Shiraz Hashim
2024-10-14 12:38 ` Dmitry Baryshkov
2024-10-11 7:11 ` Mukesh Ojha
2024-10-11 7:09 ` neil.armstrong
2024-10-14 12:29 ` Shiraz Hashim
2024-10-25 19:07 ` Konrad Dybcio
2024-10-06 19:34 ` [PATCH 0/6] Peripheral Image Loader support for Qualcomm SoCs Dmitry Baryshkov
2024-10-07 18:39 ` Mukesh Ojha
2024-10-09 13:50 ` Shiraz Hashim
-- strict thread matches above, loose matches on Subject: below --
2024-10-04 21:40 Mukesh Ojha
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=20241004212359.2263502-1-quic_mojha@quicinc.com \
--to=quic_mojha@quicinc.com \
--cc=andersson@kernel.org \
--cc=bartosz.golaszewski@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mathieu.poirier@linaro.org \
--cc=robh@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).