| Message ID | 20241004212359.2263502-1-quic_mojha@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Peripheral Image Loader support for Qualcomm SoCs | expand |
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 >
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
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
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(-)