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.
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.
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
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.
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
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?
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.
Yep, mm_vm_dump sounds like what you're looking for. You can add a call
where you like and it will go to the log UART.
On Thu, 16 Jul 2020 at 19:14, Raghu K via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Quick search indicates mm_vm_dump() and the functions it calls in
> src/mm.c should do what you want. i've not tried it or don't know the
> format, but this may be what you are looking for.
>
> -Raghu
>
> On 7/16/20 11:03 AM, Madhukar Pappireddy via Hafnium wrote:
> > Hi,
> >
> > I was wondering if there is support in Hafnium to dump page tables to a
> log file. I am new to the Hafnium project and would appreciate any help.
> Below is an example from TF-A which provides such provision.
> >
> > ......<snip>
> > VERBOSE: Translation tables state:
> > VERBOSE: Xlat regime: EL3
> > VERBOSE: Max allowed PA: 0xfffffffff
> > VERBOSE: Max allowed VA: 0xfffffffff
> > VERBOSE: Max mapped PA: 0x2f1fffff
> > VERBOSE: Max mapped VA: 0x2f1fffff
> > VERBOSE: Initial lookup level: 1
> > VERBOSE: Entries @initial lookup level: 64
> > VERBOSE: Used 3 sub-tables out of 5 (spare: 2)
> > [LV1] VA:0x0 size:0x40000000
> > [LV2] VA:0x0 size:0x200000
> > [LV3] VA:0x0 PA:0x0 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x1000 PA:0x1000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x2000 PA:0x2000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x3000 PA:0x3000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x4000 PA:0x4000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x5000 PA:0x5000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x6000 PA:0x6000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x7000 PA:0x7000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x8000 PA:0x8000 size:0x1000 MEM-RO-XN-S
> > [LV3] VA:0x9000 PA:0x9000 size:0x1000 MEM-RO-XN-S
> > [LV3] VA:0xa000 PA:0xa000 size:0x1000 MEM-RO-XN-S
> > [LV3] VA:0xb000 size:0x1000
> > [LV3] (500 invalid descriptors omitted)
> > [LV2] VA:0x200000 size:0x200000
> > [LV2] (30 invalid descriptors omitted)
> > [LV2] VA:0x4000000 size:0x200000
> > ..... <snip>
> >
> > Thanks,
> > Madhukar
> >
>
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
Quick search indicates mm_vm_dump() and the functions it calls in
src/mm.c should do what you want. i've not tried it or don't know the
format, but this may be what you are looking for.
-Raghu
On 7/16/20 11:03 AM, Madhukar Pappireddy via Hafnium wrote:
> Hi,
>
> I was wondering if there is support in Hafnium to dump page tables to a log file. I am new to the Hafnium project and would appreciate any help. Below is an example from TF-A which provides such provision.
>
> ......<snip>
> VERBOSE: Translation tables state:
> VERBOSE: Xlat regime: EL3
> VERBOSE: Max allowed PA: 0xfffffffff
> VERBOSE: Max allowed VA: 0xfffffffff
> VERBOSE: Max mapped PA: 0x2f1fffff
> VERBOSE: Max mapped VA: 0x2f1fffff
> VERBOSE: Initial lookup level: 1
> VERBOSE: Entries @initial lookup level: 64
> VERBOSE: Used 3 sub-tables out of 5 (spare: 2)
> [LV1] VA:0x0 size:0x40000000
> [LV2] VA:0x0 size:0x200000
> [LV3] VA:0x0 PA:0x0 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x1000 PA:0x1000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x2000 PA:0x2000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x3000 PA:0x3000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x4000 PA:0x4000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x5000 PA:0x5000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x6000 PA:0x6000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x7000 PA:0x7000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x8000 PA:0x8000 size:0x1000 MEM-RO-XN-S
> [LV3] VA:0x9000 PA:0x9000 size:0x1000 MEM-RO-XN-S
> [LV3] VA:0xa000 PA:0xa000 size:0x1000 MEM-RO-XN-S
> [LV3] VA:0xb000 size:0x1000
> [LV3] (500 invalid descriptors omitted)
> [LV2] VA:0x200000 size:0x200000
> [LV2] (30 invalid descriptors omitted)
> [LV2] VA:0x4000000 size:0x200000
> ..... <snip>
>
> Thanks,
> Madhukar
>
