- Hafnium - lists.trustedfirmware.org

by Olivier Deprez

Hi, As of today, the way to build Hafnium is a single make command to build Hafnium binaries (e.g. SPMC) and tests for all platforms at once. This is an overhead for deployments or integrations downstream that are only interested in building a single platform SPMC image, and are not interested in running Hafnium tests. We have a proposal to help scaling to those deployments where only an SPMC binary for a given platform is required. On the benefits side, this greatly decreases the build time for said deployments and limits build dependencies (e.g. ones within the test framework). There are certainly more complex solutions that we thought about (like segregating individual project git trees beyond 'reference') . However, the proposed change remains simple and keeps the build system backwards compatible with existing deployments. Essentially this introduces a PLATFORM command line build option for the sake of building the SPMC for one given platform (omitting tests). If required it can be combined with the existing PROJECT variable. Example usages: * make [PROJECT=reference] : builds all platforms from 'reference' project including tests (same as today) * make PLATFORM=secure_aem_v8a_fvp_vhe : builds the SPMC targeting FVP from the 'reference' project (omitting tests) * Similarly for Arm solutions, make PLATFORM=secure_tc, make PLATFORM=secure_rd_fremont * make PROJECT=project1 : make all platforms from alternate project 'project1' * make PROJECT=project2 PLATFORM=platform1 : make a single 'platform1' hafnium binary from project 'project2' See the changes: https://review.trustedfirmware.org/c/hafnium/hafnium/+/24822 https://review.trustedfirmware.org/c/hafnium/project/reference/+/24821/ Let us know if the approach sounds reasonable. Regards, Olivier.

1 year, 11 months

2
2
0 0

Manifest bindings

by Jens Wiklander

Hi, https://hafnium.readthedocs.io/en/latest/design/ffa-manifest-binding.html has a nice description of the manifest bindings. The intention is obviously to match the fields in the FF-A specification. However, the "pages-count" field in the bindings is called "page count" in the specification. Any chance of fixing this so the two fields have the same name? Thanks, Jens

2 years, 1 month

2
2
0 0

Compile errors when building Hafnium on Arm devices

by Chenxu Wang

Hi All, I try to build Hafnium v2.8 on Armv8-A device, but I got some compile errors. Here are my building scripts: ``` cd hafnium PATH=$PWD/prebuilts/linux-x64/clang/bin:$PWD/prebuilts/linux-x64/dtc:$PATH make PROJECT=reference ``` Here are some compile errors (The remainings are similar.) ``` [66/3042] CC aem_v8a_fvp_clang/obj/test/arch/arch_test.elf.dlog_test.o FAILED: aem_v8a_fvp_clang/obj/test/arch/arch_test.elf.dlog_test.o clang -MMD -MF aem_v8a_fvp_clang/obj/test/arch/arch_test.elf.dlog_test.o.d -DVM_TOOLCHAIN=0 -DGIC_VERSION=3 -DGICD_BASE=0x2f000000 -DGICR_BASE=0x2f100000 -DGICR_FRAMES=8 -DHEAP_PAGES=180 -DMAX_CPUS=8 -DMAX_VMS=16 -DLOG_LEVEL=LOG_LEVEL_INFO -DENABLE_ASSERTIONS=1 -DPARTITION_MAX_MEMORY_REGIONS=8 -DPARTITION_MAX_DEVICE_REGIONS=8 -DPARTITION_MAX_INTERRUPTS_PER_DEVICE=4 -DPARTITION_MAX_STREAMS_PER_DEVICE=4 -DHF_NUM_INTIDS=64 -DSECURE_WORLD=0 -DENABLE_VHE=0 -I../../inc -I../../inc/vmapi -I../../src/arch/aarch64/inc -Iaem_v8a_fvp_clang/gen/offset_size_header -I../../test/inc -ffunction-sections -fdata-sections -flto -fno-builtin -ffreestanding -fpic -mcpu=cortex-a57+nofp -mstrict-align -mgeneral-regs-only -target aarch64-none-eabi -fcolor-diagnostics -nostdinc -isystem /include -isystem hafnium/inc/system -g -Wall -O2 -Wpedantic -Werror -fstack-protector-all -std=c11 -c ../../test/arch/dlog_test.c -o aem_v8a_fvp_clang/obj/test/arch/arch_test.elf.dlog_test.o In file included from ../../test/arch/dlog_test.c:9: ../../inc/hf/dlog.h:11:10: fatal error: 'stdarg.h' file not found #include <stdarg.h> ^~~~~~~~~~ 1 error generated. [67/3042] CC aem_v8a_fvp_clang/obj/src/vm.vm.o FAILED: aem_v8a_fvp_clang/obj/src/vm.vm.o clang -MMD -MF aem_v8a_fvp_clang/obj/src/vm.vm.o.d -DVM_TOOLCHAIN=0 -DGIC_VERSION=3 -DGICD_BASE=0x2f000000 -DGICR_BASE=0x2f100000 -DGICR_FRAMES=8 -DHEAP_PAGES=180 -DMAX_CPUS=8 -DMAX_VMS=16 -DLOG_LEVEL=LOG_LEVEL_INFO -DENABLE_ASSERTIONS=1 -DPARTITION_MAX_MEMORY_REGIONS=8 -DPARTITION_MAX_DEVICE_REGIONS=8 -DPARTITION_MAX_INTERRUPTS_PER_DEVICE=4 -DPARTITION_MAX_STREAMS_PER_DEVICE=4 -DHF_NUM_INTIDS=64 -DSECURE_WORLD=0 -DENABLE_VHE=0 -I../../inc -I../../inc/vmapi -I../../src/arch/aarch64/inc -Iaem_v8a_fvp_clang/gen/offset_size_header -ffunction-sections -fdata-sections -flto -fno-builtin -ffreestanding -fpic -mcpu=cortex-a57+nofp -mstrict-align -mgeneral-regs-only -target aarch64-none-eabi -fcolor-diagnostics -nostdinc -isystem /include -isystem hafnium/inc/system -g -Wall -O2 -Wpedantic -Werror -fstack-protector-all -std=c11 -c ../../src/vm.c -o aem_v8a_fvp_clang/obj/src/vm.vm.o In file included from ../../src/vm.c:9: ../../inc/hf/vm.h:11:10: fatal error: 'stdatomic.h' file not found #include <stdatomic.h> ^~~~~~~~~~~~~ 1 error generated. ``` Can someone help me? Sincerely, WANG Chenxu

2 years, 1 month

2
2
0 0

New TrustedFirmware Discord Server

by Don Harbin

Hi All, Note you may have received another instance of this note but when I attempted to send to all TF ML's simultaneously it seemed to fail, so sending to each one at a time. Sorry about that. :/ We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 1 month

1
0
0 0

Fwd: New TrustedFirmware Discord Server

by Don Harbin

Hi All, To all TF maillists in case all aren't yet aware. We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. I've attached a recent screenshot from the #general channel as a sample of the interface and usages. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 1 month

1
0
0 0

Hafnium documentation moved to readthedocs

by Olivier Deprez

Hi, This is to inform that the Hafnium documentation is being migrated to its own ReadTheDocs project (from TF-A RTD project): https://hafnium.readthedocs.io This primarily concerns the SPM design doc and threat model. Hafnium documentation changes should target hafnium tree moving forward: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/docs The remaining work over the coming days is: -creating a docs watcher automatically triggering RTD builds. -polishing few leftovers originating from TF-A in migrated documents. -cleanly removing the now duplicated docs from TF-A tree. If any question feel free to reach to the team. Regards, Olivier.

2 years, 3 months

1
0
0 0

multiple SP secondary boot

by 梅建强(禹夜)

Hi, Madhu, Olivier, I am glad that I have the same understanding as both of you about description in FF-A 1.1 18.3.2.1.1. Other points to discuss: >For SPs beyond the first SP, it is up to the normal world driver to invoke FFA_RUN for each secondary vCPU. OK, I basically understand what you said. But I did not use this interface. I need to make it clear for my current implementation for booting secondary vCPUs on SPs beyond the first SP. I connect all vCPUs with the same index on all SP. If there is no vCPU for the current index, just skip to next vCPU with the same index on next SP. So for each index, we can build a vCPU boot list. Later when the nwd boots, upon invocation of PSCI_CPU_ON, each secondary vCPU for the first SP get initialized. Then Hafnium starts the next secondary vCPU on SP beyond the first SP according to the boot list. At present, we have implemented it and tested it without problems. Is this a violation of the FF-A spe, or is there any other problem? >Note I don't believe the current optee linux driver supports the above. >In which case the scenario you describe (multiple optee instances) might not work out of the box. Agree. >Also note there must be other issues like how to handle the secure storage when multiple optee instances exists. Could you describe it in more detail? Thanks for your supports. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez <Olivier.Deprez(a)arm.com> 发送时间：2023年7月17日(星期一) 22:29 收件人：Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com>; 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com> 抄　送：hafnium <hafnium(a)lists.trustedfirmware.org>; 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> 主　题：Re: [Hafnium] multiple SP secondary boot Hi, I'm adding to Madhu's reply: At TF-A /secure boot time, before nwd is initialized, the first vCPU for each SP is resumed in sequence by the SPMC. It gives the opportunity for each SP to define a secondary boot address for later resuming of secondary vCPUs. Later when the nwd boots, upon invocation of PSCI_CPU_ON, each secondary vCPU for the first SP get initialized. For SPs beyond the first SP, it is up to the normal world driver to invoke FFA_RUN for each secondary vCPU. Note I don't believe the current optee linux driver supports the above. In which case the scenario you describe (multiple optee instances) might not work out of the box. Also note there must be other issues like how to handle the secure storage when multiple optee instances exists. This might work though if you decide to strip down optee instances to a very minimal set of features, that do not use the same resources. We might help further if you provide a bit more details about the intended setup/scenario. Regards, Olivier. From: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Sent: 17 July 2023 16:19 To: 梅建强(禹夜) <meijianqiang.mjq(a)alibaba-inc.com>; Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: RE: [Hafnium] multiple SP secondary boot Hi Yuye, I think the following sentence in the spec is slightly confusing. " For each SP and the SPMC, the Framework assumes that the same entry point address is used for initializing any execution context during a secondary cold boot." I believe what it meant is that the entry point address for any secondary execution context of a particular SP is the same. Note that the entry point of secondary execution contexts belonging to another SP is different than the one previously registered. I can confirm that Hafnium adheres to the above statement. Please note that the cold boot flow is different for secondary cores compared to primary core. On the primary core, SPMC initializes the execution contexts of all SPs( refer to [1]). However, execution contexts of non-primary SP on secondary cores need CPU cycles to be allocated by the NWd scheduler through the FFA_RUN interface(refer to [2]). Hopefully, I was able to answer your questions. [1] https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/p… <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/p… > [2] https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1047 <https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1047 > Thanks, Madhu -----Original Message----- From: 梅建强(禹夜) via Hafnium <hafnium(a)lists.trustedfirmware.org> Sent: Saturday, July 15, 2023 4:54 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium <hafnium(a)lists.trustedfirmware.org>; 高海源(码源) <haiyuan.ghy(a)alibaba-inc.com>; 王一蒙(北见) <wym389994(a)alibaba-inc.com>; 黄明(连一) <hm281385(a)alibaba-inc.com> Subject: [Hafnium] multiple SP secondary boot Hi, Olivier, There's a problem I'd like to discuss with you. In the FF-A 1.1 18.3.2.1.1 section, it is described as follows: For each SP and the SPMC, the Framework assumes that the same entry point address is used for initializing any execution context during a secondary cold boot. This does not seem to make sense for entry point addresses of multiple SP. In addition, I do not see support for the secondary boot of the multiple SP in the current implementation of Hafnium. If I have multiple optee instances of MP type, how should I design the cold secondary boot flow for multiple SP? My idea is to build a vCPU list with the same index between VMs, just like primary boot flow, as shown in the code below: void vcpu_update_boot(struct vcpu *vcpu) { struct vcpu *current = NULL; struct vcpu *previous = NULL; if (boot_vcpu == NULL) { boot_vcpu = vcpu; return; } current = boot_vcpu; while (current != NULL && current->vm->boot_order <= vcpu->vm->boot_order) { previous = current; current = current->next_boot; } if (previous != NULL) { previous->next_boot = vcpu; } else { boot_vcpu = vcpu; } vcpu->next_boot = current; } Anyone else have some good suggestions? Thanks for the support. Regards, Yuye. -- Hafnium mailing list -- hafnium(a)lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave(a)lists.trustedfirmware.org

2 years, 3 months

2
1
0 0

Question about SMMU S-2 translation

by Chenxu Wang

Hi all, I'd like to ask some questions about how the SMMU S-2 translation works. My questions are as follows: 1. When SMMU performs Stage-2 translation (I mean, fetches the translation table and walks it), is it constrained by GPC on CPU MMU, or GPC on SMMU, or both? For example, assume I configure the PAS of the non-secure SMMU S-2 translation table as "secure/realm/root PAS" in CPU MMU GPC, but "non-secure PAS" in SMMU (e.g., the SMMU for TestEngine on FVP) GPC, will the SMMU successfully perform S-2 translation? Or in another example, assume I configure the PAS of the non-secure SMMU S-2 translation table as "non-secure PAS" in CPU MMU GPC, but "secure/realm/root PAS" in SMMU (e.g., the SMMU for TestEngine on FVP) GPC, will the SMMU successfully perform S-2 translation? 2. Currently I use Hafnium to configure the SMMU. Due to memory limitation, I want to place the SMMU Stage-2 table in DRAM2 (starting from 0x8_8000_0000, but this region is not mapped in Hafnium). Since I think the SMMU S-2 translation is influenced by EL2 S-1 translation (really?), can I turn off the EL2 S-1 translation in Hafnium to avoid this problem? If yes, how to do it? Sincerely, WANG Chenxu

2 years, 3 months

2
1
0 0

multiple SP secondary boot

by 梅建强(禹夜)

Hi, Olivier, There's a problem I'd like to discuss with you. In the FF-A 1.1 18.3.2.1.1 section, it is described as follows: For each SP and the SPMC, the Framework assumes that the same entry point address is used for initializing any execution context during a secondary cold boot. This does not seem to make sense for entry point addresses of multiple SP. In addition, I do not see support for the secondary boot of the multiple SP in the current implementation of Hafnium. If I have multiple optee instances of MP type, how should I design the cold secondary boot flow for multiple SP? My idea is to build a vCPU list with the same index between VMs, just like primary boot flow, as shown in the code below: void vcpu_update_boot(struct vcpu *vcpu) { struct vcpu *current = NULL; struct vcpu *previous = NULL; if (boot_vcpu == NULL) { boot_vcpu = vcpu; return; } current = boot_vcpu; while (current != NULL && current->vm->boot_order <= vcpu->vm->boot_order) { previous = current; current = current->next_boot; } if (previous != NULL) { previous->next_boot = vcpu; } else { boot_vcpu = vcpu; } vcpu->next_boot = current; } Anyone else have some good suggestions? Thanks for the support. Regards, Yuye.

2 years, 3 months

3
2
0 0

Re: optee_benchmark found optee_os function vm_set_ctx() spent much time

by jens.wiklander＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

2 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

Hafnium