.../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(-)
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
On Sat, Oct 05, 2024 at 02:53:53AM GMT, Mukesh Ojha wrote: > 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. Can you follow the approach that has been implemented for existing systems (ChromeOS) not using QHEE? See drivers/remoteproc/qcom_q6v5_adsp.c If this approach can not be used, please describe why. > > - 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 > -- With best wishes Dmitry
On Sun, Oct 06, 2024 at 10:34:19PM +0300, Dmitry Baryshkov wrote: > On Sat, Oct 05, 2024 at 02:53:53AM GMT, Mukesh Ojha wrote: > > 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. > > Can you follow the approach that has been implemented for existing > systems (ChromeOS) not using QHEE? See drivers/remoteproc/qcom_q6v5_adsp.c > If this approach can not be used, please describe why. > The intent is to reuse same PAS based remoteproc implementation assisted by TZ with or without QHEE while qcom_q6v5_adsp.c caters to independent control at Linux. So it better suites to support it from qcom_q6v5_pas.c . regards Shiraz
On Sun, Oct 06, 2024 at 10:34:19PM +0300, Dmitry Baryshkov wrote: > On Sat, Oct 05, 2024 at 02:53:53AM GMT, Mukesh Ojha wrote: > > 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. > > Can you follow the approach that has been implemented for existing > systems (ChromeOS) not using QHEE? See drivers/remoteproc/qcom_q6v5_adsp.c > If this approach can not be used, please describe why. > I believe, drivers/remoteproc/qcom_q6v5_adsp.c does not follow TZ's PAS method (Secure) of handling remoteproc that may be the reason it has been kept separately from drivers/remoteproc/qcom_q6v5_pas.c . If we keep this implementation align with current PAS driver we would acheive more code reusability with less code change. However, I am not against, if we want to keep this as separate driver with qcom_q6v5_pas_common.c shared between the current pas driver with QHEE vs this implementation with non-QHEE. -Mukesh > > > > - 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 > > > > -- > With best wishes > Dmitry
© 2016 - 2024 Red Hat, Inc.