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@lists.trustedfirmware.org On Behalf Of Andrew Walbran via Hafnium Sent: Tuesday, August 4, 2020 3:13 AM To: Olivier Deprez Olivier.Deprez@arm.com Cc: hafnium@lists.trustedfirmware.org Subject: Re: [Hafnium] FF-A id ranges
On Mon, 3 Aug 2020 at 18:03, Olivier Deprez via Hafnium < hafnium@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.
Hi,
Thanks Andrew & Raghu. Option 1/ is my preferred option as well.
Although using SECURE_WORLD macro in headers doesn't seem to scale well atm.
e.g. src/manifest.c may include a header which uses such macro, although as it is a generic C file it won't get -DSECURE_WORLD=1 when building the secure version of Hafnium. This would require defining SECURE_WORLD macro for every C file, and not just the aarch64 files (https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/hy...)
I'm considering other options like using a C arch function returning the base for VM ids, rather than relying on preprocessor.
Regards, Olivier.
________________________________________ From: raghu.ncstate@icloud.com raghu.ncstate@icloud.com Sent: 04 August 2020 17:23 To: Olivier Deprez Cc: hafnium@lists.trustedfirmware.org Subject: RE: [Hafnium] FF-A id ranges
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@lists.trustedfirmware.org On Behalf Of Andrew Walbran via Hafnium Sent: Tuesday, August 4, 2020 3:13 AM To: Olivier Deprez Olivier.Deprez@arm.com Cc: hafnium@lists.trustedfirmware.org Subject: Re: [Hafnium] FF-A id ranges
On Mon, 3 Aug 2020 at 18:03, Olivier Deprez via Hafnium < hafnium@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.
hafnium@lists.trustedfirmware.org
-
Olivier Deprez -
raghu.ncstate＠icloud.com