- Hafnium - lists.trustedfirmware.org

Re: [Hafnium] Stage-2 page faults reports to EL1

by Andrew Walbran

On Mon, 3 Aug 2020 at 10:32, Olivier Deprez via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > On a Stage-2 page fault, Hafnium does not report FAR_EL2 to FAR_EL1 in > inject_el1_exception . > > As a consequence EL1 is resumed although it cannot determine the faulting > address from FAR_EL1 (which likely holds zero or some other remnant value?). > > Is this intended? > That sounds like a bug. Fuad, did you work on this? Any idea what's going on here? (Note, Fuad is away this week but can hopefully reply next week.)

4 years, 9 months

2
1
0 0

Re: [Hafnium] [TF-A] Fw: Automate generation of Partition's specific configuration

by raghu.ncstate＠icloud.com

Hi, It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build? The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice. Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joao Alves via TF-A Sent: Monday, August 3, 2020 10:08 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Fw: Automate generation of Partition's specific configuration Hi all, Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well. Best regards, João Alves _____ From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org <mailto:hafnium-bounces@lists.trustedfirmware.org> > on behalf of Joao Alves via Hafnium <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Sent: Monday, August 3, 2020 5:59 PM To: hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> <hafnium(a)lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> > Subject: [Hafnium] Automate generation of Partition's specific configuration Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves -- Hafnium mailing list Hafnium(a)lists.trustedfirmware.org <mailto:Hafnium@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 9 months

1
0
0 0

Re: [Hafnium] FF-A id ranges

by raghu.ncstate＠icloud.com

The static partitioning scheme and option 1 looks fine to me. Option 2 is fine too but not sure I see why a platform would want to or need to customize the ID range. -----Original Message----- From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Walbran via Hafnium Sent: Tuesday, August 4, 2020 3:13 AM To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: hafnium(a)lists.trustedfirmware.org Subject: Re: [Hafnium] FF-A id ranges On Mon, 3 Aug 2020 at 18:03, Olivier Deprez via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > We consider updating the range of FF-A IDs for Secure Partitions > running in SWd on top of Hafnium. > > Bit 15 in FF-A IDs can serve to hint the world type into which the > VM/SP resides. > FF-A id bit 15 clear => id space [1 : 0x7fff] reserved for VMs on top > of NWd Hafnium FF-A id bit 15 set => id space [0x8001 : 0xffff] > reserved for SPs on top of SWd Hafnium > > 0 reserved to the Hypervisor itself. > 0x8000 reserved for the TEE (or later for the SPMC). > > One way to achieve this is to define a static value for the base of > FF-A ids, see: > > https://review.trustedfirmware.org/c/hafnium/hafnium/+/5165/1/inc/vmap > i/hf/types.h#30 > > The intent is to set 0 for the NWd Hypervisor build and 0x8000 for the > SWd SPMC build. > 1/ This can be done through the SECURE_WORLD macro (although this > macro is only available to src/arch/aarch64/* files) 2/ This can be > passed as a platform parameter in the build flow (e.g. same way as > max_vms) > > There are others ways rather than using id ranges, e.g. setting the > bit explicitly in FF-A IDs when doing the SPMC build. > > Any thoughts? > I guess Hafnium will need to know not just what IDs to use for the world it is operating in, but also how to interact with the other world. This seems like an arch-specific concept, so maybe some of the constants currently defined in hf/types should be moved into an aarch64 directory so they can be defined based on the SECURE_WORLD macro? This is essentially your option 1 above.

4 years, 9 months

2
1
0 0

Re: [Hafnium] FF-A id ranges

by Andrew Walbran

On Mon, 3 Aug 2020 at 18:03, Olivier Deprez via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > We consider updating the range of FF-A IDs for Secure Partitions running > in SWd on top of Hafnium. > > Bit 15 in FF-A IDs can serve to hint the world type into which the VM/SP > resides. > FF-A id bit 15 clear => id space [1 : 0x7fff] reserved for VMs on top of > NWd Hafnium > FF-A id bit 15 set => id space [0x8001 : 0xffff] reserved for SPs on top > of SWd Hafnium > > 0 reserved to the Hypervisor itself. > 0x8000 reserved for the TEE (or later for the SPMC). > > One way to achieve this is to define a static value for the base of FF-A > ids, see: > > https://review.trustedfirmware.org/c/hafnium/hafnium/+/5165/1/inc/vmapi/hf/… > > The intent is to set 0 for the NWd Hypervisor build and 0x8000 for the SWd > SPMC build. > 1/ This can be done through the SECURE_WORLD macro (although this macro is > only available to src/arch/aarch64/* files) > 2/ This can be passed as a platform parameter in the build flow (e.g. same > way as max_vms) > > There are others ways rather than using id ranges, e.g. setting the bit > explicitly in FF-A IDs when doing the SPMC build. > > Any thoughts? > I guess Hafnium will need to know not just what IDs to use for the world it is operating in, but also how to interact with the other world. This seems like an arch-specific concept, so maybe some of the constants currently defined in hf/types should be moved into an aarch64 directory so they can be defined based on the SECURE_WORLD macro? This is essentially your option 1 above.

4 years, 9 months

1
0
0 0

FF-A id ranges

by Olivier Deprez

Hi, We consider updating the range of FF-A IDs for Secure Partitions running in SWd on top of Hafnium. Bit 15 in FF-A IDs can serve to hint the world type into which the VM/SP resides. FF-A id bit 15 clear => id space [1 : 0x7fff] reserved for VMs on top of NWd Hafnium FF-A id bit 15 set => id space [0x8001 : 0xffff] reserved for SPs on top of SWd Hafnium 0 reserved to the Hypervisor itself. 0x8000 reserved for the TEE (or later for the SPMC). One way to achieve this is to define a static value for the base of FF-A ids, see: https://review.trustedfirmware.org/c/hafnium/hafnium/+/5165/1/inc/vmapi/hf/… The intent is to set 0 for the NWd Hypervisor build and 0x8000 for the SWd SPMC build. 1/ This can be done through the SECURE_WORLD macro (although this macro is only available to src/arch/aarch64/* files) 2/ This can be passed as a platform parameter in the build flow (e.g. same way as max_vms) There are others ways rather than using id ranges, e.g. setting the bit explicitly in FF-A IDs when doing the SPMC build. Any thoughts? Regards, Olivier.

4 years, 9 months

1
0
0 0

Automate generation of Partition's specific configuration

by Joao Alves

Hello all, I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium. There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions: hypervisor { compatible = "hafnium,hafnium"; vm1 { is_ffa_partition; debug_name = "cactus-primary"; load_address = <0x7000000>; }; vm2 { is_ffa_partition; debug_name = "cactus-secondary"; load_address = <0x7100000>; vcpu_count = <2>; mem_size = <1048576>; }; }; Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address". If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files. In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files. Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150. The implementation is divided between two scripts: * "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files. * "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration. Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation. The above files contain a lot of comments on how to use them, and also describing the implementation. If the obtained feedback is good, I can work on integrating this in TF-A's build-system. Let me know if anyone has questions. Best regards, João Alves

4 years, 9 months

1
0
0 0

Stage-2 page faults reports to EL1

by Olivier Deprez

Hi, On a Stage-2 page fault, Hafnium does not report FAR_EL2 to FAR_EL1 in inject_el1_exception . As a consequence EL1 is resumed although it cannot determine the faulting address from FAR_EL1 (which likely holds zero or some other remnant value?). Is this intended? Regards, Olivier.

4 years, 9 months

1
0
0 0

Re: [Hafnium] FFA_FEATURES and FFA_RXTX_MAP_64

by Achin Gupta

Hi Olivier/Andrew, > On 22 Jul 2020, at 15:08, Andrew Walbran via Hafnium <hafnium(a)lists.trustedfirmware.org> wrote: > > On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium < > hafnium(a)lists.trustedfirmware.org> wrote: > >> Hi, >> >> We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented >> ABIs with the SMC32 convention, but FFA_RXTX_MAP_64: >> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430 Did you mean : https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1510 >> >> On the other hand ffa_handler discards the SMC convention bit: >> >> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h… What is the rationale behind this? As per the SMCCC: -1 must be returned for an SMC64/HVC64 call from AArch32 state or an unknown function ID. In the latter case, if the spec don’t list it then it ain’t there :) >> >> It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail, >> although this does not prevent effectively calling the same ABI with the >> SMC32 convention. >> >> Is there some fine tuning to do here? >> Should we just discard the SMC convention bit in api_ffa_features? >> > > I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses > for the buffers that it passes. We should probably return an error from > ffa_handler if a VM tries to call FFA_RXTX_MAP_32. Does Hafnium not intend to work with AArch32 SPs? Is this is a requirement that has been spelt out so the community ensures no AArch32 SPs are presented. The SPM design doc catered for this requirement the last time I checked. > > For other functions I guess we could make it support either, by discarding > the SMC convention bit in FFA_FEATURES as you suggest. Are there any other > differences between the SMC32 and SMC64 convention which we need to take > care of? I think we need to make a more informed choice. For example, what if FFA_FEATURES is called with the non-existent 64-bit FID for FFA_ID_GET, FFA_RXTX_UNMAP, FFA_PARTITION_INFO_GET, FFA_MEM_FRAG_RX, FFA_MEM_FRAG_TX etc. Cheers, Achin > -- > Hafnium mailing list > Hafnium(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/hafnium

4 years, 10 months

2
3
0 0

Re: [Hafnium] FFA_FEATURES and FFA_RXTX_MAP_64

by Andrew Walbran

On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium < hafnium(a)lists.trustedfirmware.org> wrote: > Hi, > > We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented > ABIs with the SMC32 convention, but FFA_RXTX_MAP_64: > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430 > > On the other hand ffa_handler discards the SMC convention bit: > > https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h… > > It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail, > although this does not prevent effectively calling the same ABI with the > SMC32 convention. > > Is there some fine tuning to do here? > Should we just discard the SMC convention bit in api_ffa_features? > I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses for the buffers that it passes. We should probably return an error from ffa_handler if a VM tries to call FFA_RXTX_MAP_32. For other functions I guess we could make it support either, by discarding the SMC convention bit in FFA_FEATURES as you suggest. Are there any other differences between the SMC32 and SMC64 convention which we need to take care of?

4 years, 10 months

1
0
0 0

FFA_FEATURES and FFA_RXTX_MAP_64

by Olivier Deprez

Hi, We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented ABIs with the SMC32 convention, but FFA_RXTX_MAP_64: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430 On the other hand ffa_handler discards the SMC convention bit: https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h… It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail, although this does not prevent effectively calling the same ABI with the SMC32 convention. Is there some fine tuning to do here? Should we just discard the SMC convention bit in api_ffa_features? Regards, Olivier.

4 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

Hafnium