Secure remoteproc support for kvm for Leman SoC #204
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
commit f4e526f ("soc: qcom: mdt_loader: Extract PAS operations") move pas specific code from __qcom_mdt_load() to a separate function qcom_mdt_pas_init() after which the pas_init variable became unused in __qcom_mdt_load(). Remove pas_init argument from __qcom_mdt_load(). Link: https://lore.kernel.org/lkml/[email protected]/ Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Mukesh Ojha <[email protected]>
pas id is not used in qcom_mdt_load_no_init() and it should not be used as it is non-PAS specific function and has no relation to PAS specific mechanism. Link: https://lore.kernel.org/lkml/[email protected]/ Reviewed-by: Dikshita Agarwal <[email protected]> Acked-by: Jeff Johnson <[email protected]> # drivers/net/wireless/ath/ath12k/ahb.c Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Mukesh Ojha <[email protected]>
fw_name in qcom_mdt_bins_are_split() seems unused now, it may have used in the past for logging it but due to code refactor this parameter is unused now. Link: https://lore.kernel.org/lkml/[email protected]/ Reviewed-by: Jeff Johnson <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Mukesh Ojha <[email protected]>
Most Qualcomm platforms feature Gunyah hypervisor which handles IOMMU configuration for remote processor and when it is not present, the operating system must perform these configurations instead and for that firmware stream should be presented to the operating system. Hence, add iommus property as optional property for PAS supported devices. Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-1-de841623af3c@oss.qualcomm.com/ Acked-by: Rob Herring (Arm) <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Mukesh Ojha <[email protected]>
Peripheral and pas_id refers to unique id for a subsystem and used only when peripheral authentication service from secure world is utilized. Lets rename peripheral to pas_id to reflect closer to its meaning. Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-2-de841623af3c@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Mukesh Ojha <[email protected]>
…d destroy helper When the Peripheral Authentication Service (PAS) method runs on a SoC where Linux operates at EL2 (i.e., without the Gunyah hypervisor), the reset sequences are handled by TrustZone. In such cases, Linux must perform additional steps before invoking PAS SMC calls, such as creating a SHM bridge. Therefore, PAS SMC calls require awareness and handling of these additional steps when Linux runs at EL2. To support this, there is a need for a data structure that can be initialized prior to invoking any SMC or MDT functions. This structure allows those functions to determine whether they are operating in the presence or absence of the Gunyah hypervisor and behave accordingly. Currently, remoteproc and non-remoteproc subsystems use different variants of the MDT loader helper API, primarily due to differences in metadata context handling. Remoteproc subsystems retain the metadata context until authentication and reset are completed, while non-remoteproc subsystems (e.g., video, graphics, IPA, etc.) do not retain the metadata context and can free it within the qcom_scm_pas_init() call by passing a NULL context parameter and due to these differences, it is not possible to extend metadata context handling to support remoteproc and non remoteproc subsystem use PAS operations, when Linux operates at EL2. Add PAS context data structure and helper functions to initialize and destroy it. Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-3-de841623af3c@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Mukesh Ojha <[email protected]>
…ad() function Add a PAS context-aware qcom_mdt_pas_load() function for remote processor drivers, which can use the context pointer returned from qcom_scm_pas_ctx_init() to perform metadata verification and memory setup via SMC calls. The qcom_mdt_pas_load() and qcom_mdt_load() functions are almost similar. Clients using the PAS context-based data structure can adopt qcom_mdt_pas_load(), and in the future, all users of qcom_mdt_load() could be migrated to use qcom_mdt_pas_load() instead. Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-4-de841623af3c@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <[email protected]>
…structure As a superset of the existing metadata context, the PAS context structure enables both remoteproc and non-remoteproc subsystems to better support scenarios where the SoC runs with or without the Gunyah hypervisor. To reflect this, relevant SMC and metadata functions are updated to incorporate PAS context awareness. Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-5-de841623af3c@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <[email protected]>
…nction For memory passed to TrustZone (TZ), it must either be part of a pool registered with TZ or explicitly registered via SHMbridge SMC calls. When Gunyah hypervisor is present, PAS SMC calls from Linux running at EL1 are trapped by Gunyah running @ EL2, which handles SHMbridge creation for both metadata and remoteproc carveout memory before invoking the calls to TZ. On SoCs running with a non-Gunyah-based hypervisor, Linux must take responsibility for creating the SHM bridge before invoking PAS SMC calls. For the auth_and_reset() call, the remoteproc carveout memory must first be registered with TZ via a SHMbridge SMC call and once authentication and reset are complete, the SHMbridge memory can be deregistered. Introduce qcom_scm_pas_prepare_and_auth_reset(), which sets up the SHM bridge over the remoteproc carveout memory when Linux operates at EL2. This behavior is indicated by a new field added to the PAS context data structure. The function then invokes the auth_and_reset SMC call. Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-6-de841623af3c@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <[email protected]>
Simplify qcom_scm_pas_init_image() by making the memory allocation, copy and free operations done in a separate function than the actual SMC call. Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-7-de841623af3c@oss.qualcomm.com/ Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Mukesh Ojha <[email protected]>
…nning without QHEE On SoCs running with a non-Gunyah-based hypervisor, Linux must take responsibility for creating the SHM bridge both for metadata (before calling qcom_scm_pas_init_image()) and for remoteproc memory (before calling qcom_scm_pas_auth_and_reset()). We have taken care the things required for qcom_scm_pas_auth_and_reset(). Lets put these awareness of above conditions into qcom_scm_pas_init_image() and qcom_scm_pas_metadata_release(). Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-8-de841623af3c@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <[email protected]>
… resource table Qualcomm remote processor may rely on Static and Dynamic resources for it to be functional. Static resources are fixed like for example, memory-mapped addresses required by the subsystem and dynamic resources, such as shared memory in DDR etc., are determined at runtime during the boot process. For most of the Qualcomm SoCs, when run with Gunyah or older QHEE hypervisor, all the resources whether it is static or dynamic, is managed by the hypervisor. Dynamic resources if it is present for a remote processor will always be coming from secure world via SMC call while static resources may be present in remote processor firmware binary or it may be coming qcom_scm_pas_get_rsc_table() SMC call along with dynamic resources. Some of the remote processor drivers, such as video, GPU, IPA, etc., do not check whether resources are present in their remote processor firmware binary. In such cases, the caller of this function should set input_rt and input_rt_size as NULL and zero respectively. Remoteproc framework has method to check whether firmware binary contain resources or not and they should be pass resource table pointer to input_rt and resource table size to input_rt_size and this will be forwarded to TrustZone for authentication. TrustZone will then append the dynamic resources and return the complete resource table in output_rt More about documentation on resource table format can be found in include/linux/remoteproc.h Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-9-de841623af3c@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <[email protected]>
…s via SMC call Qualcomm remote processor may rely on static and dynamic resources for it to be functional. For most of the Qualcomm SoCs, when run with Gunyah or older QHEE hypervisor, all the resources whether it is static or dynamic, is managed by the hypervisor. Dynamic resources if it is present for a remote processor will always be coming from secure world via SMC call while static resources may be present in remote processor firmware binary or it may be coming from SMC call along with dynamic resources. Remoteproc already has method like rproc_elf_load_rsc_table() to check firmware binary has resources or not and if it is not having then we pass NULL and zero as input resource table and its size argument respectively to qcom_scm_pas_get_rsc_table() and while it has resource present then it should pass the present resources to Trustzone(TZ) so that it could authenticate the present resources and append dynamic resource to return in output_rt argument along with authenticated resources. Extend parse_fw callback to include SMC call to get resources from Trustzone and to leverage resource table parsing and mapping and unmapping code from the remoteproc framework. Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-10-de841623af3c@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <[email protected]>
… managed by Linux Most Qualcomm platforms feature Gunyah hypervisor, which typically handles IOMMU configuration. This includes mapping memory regions and device memory resources for remote processors by intercepting qcom_scm_pas_auth_and_reset() calls. These mappings are later removed during teardown. Additionally, SHM bridge setup is required to enable memory protection for both remoteproc metadata and its memory regions. When the aforementioned hypervisor is absent, the operating system must perform these configurations instead. When Linux runs as the hypervisor (@ EL2) on a SoC, it will have its own device tree overlay file that specifies the firmware stream ID now managed by Linux for a particular remote processor. If the iommus property is specified in the remoteproc device tree node, it indicates that IOMMU configuration must be handled by Linux. In this case, the has_iommu flag is set for the remote processor, which ensures that the resource table, carveouts, and SHM bridge are properly configured before memory is passed to TrustZone for authentication. Otherwise, the has_iommu flag remains unset, which indicates default behavior. Enables Secure PAS support for remote processors when IOMMU configuration is managed by Linux. Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-11-de841623af3c@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <[email protected]>
All the Lemans IOT variants boards are using Gunyah hypervisor which means that, so far, Linux-based OS could only boot in EL1 on those devices. However, it is possible for us to boot Linux at EL2 on these devices [1]. When running under Gunyah, remote processor firmware IOMMU streams is controlled by the Gunyah however when Linux take ownership of it in EL2, It need to configure it properly to use remote processor. Add a EL2-specific DT overlay and apply it to Lemans IOT variant devices to create -el2.dtb for each of them alongside "normal" dtb. [1] https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-4/boot-developer-touchpoints.html#uefi Link: https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-12-de841623af3c@oss.qualcomm.com/ Signed-off-by: Mukesh Ojha <[email protected]>
@shashim-quic: Shall i move binding and device tree change as a separate pull request? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
patch series is based on v4 sent in upstream
mdtloader series:
https://lore.kernel.org/lkml/[email protected]/
v4:
https://lore.kernel.org/lkml/20251007-kvm_rprocv4_next-20251007-v4-0-de841623af3c@oss.qualcomm.com/
There was problem from my side for which this pull request got closed
#203
please review this one.