Hi,
I've come across the same question when recently working on some patches for the Hafnium CI (https://review.trustedfirmware.org/c/hafnium/hafnium/+/7405).
I was trying to setup a standalone SP, trying to reuse most of what was available for a primary VM. I ended up taking the approach of defining a source_set specific to the standalone SP (https://review.trustedfirmware.org/c/hafnium/hafnium/+/7405/22/test/hftest/…), extending only the public configurations. To build the SP, just defined a vm_kernel target referencing the newly defined source_set (https://review.trustedfirmware.org/c/hafnium/hafnium/+/7405/22/test/vmapi/f…) in the target's dependencies.
The documentation for the source_set (https://gn.googlesource.com/gn/+/master/docs/reference.md#func_source_set) says: "In most cases, a source set will behave like a static library, except no actual library file will be produced.".
Because of this, I thought of the source_set as "non-reconfigurable", therefore the above-described approach.
Someone could please comment, but my understanding is that this is the way to do it.
I hope this helps.
Best regards,
João Alves
________________________________
From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Andrew Walbran via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: Tuesday, February 16, 2021 4:20 PM
To: Raghu K <raghu.ncstate(a)icloud.com>
Cc: hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>
Subject: Re: [Hafnium] GN build system Question
I thought it would work to set the defines directly on the vm_kernel
target, but apparently not. The only other way I can think of is to define
a new toolchain, but that's probably worse than just making a copy of the
source_set with the defines you want added. I'm not really a GN expert
though.
On Tue, 16 Feb 2021 at 15:36, Raghu Krishnamurthy via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
>
>
> I'm experimenting with a few things with hafnium tests and had a question
> of
> how(or what is the right way) to achieve the following with the GN build
> system.
>
> I'm using the primary_with_secondaries test, to make a few modifications
> for
> an experiment. I want to be able to compile this test suite in such a way
> that the service_vm1 target(a vm_kernel target) is compiled with a
> different
> set(or additional set) of defines but not service_vm2 or service_vm3. I'm
> looking at the test/vmapi/primary_with_secondaries/services/BUILD.gn file
> for these targets. More concretely, I want service_vm1 to be compiled with
> -DFOO=1 in addition to existing defines and service_vm2/3 to be compiled
> without -DFOO=1.
>
> I cant seem to find a way to force/push down extra defines on the
> source_sets referenced in the deps field at the vm_kernel("service_vm1")
> target. I know the other way(source_sets propagating their configs upwards
> to targets that depend on it through public_configs) is possible but I'd
> effectively like to do the reverse of it.
>
>
>
> Should I just create another vm_kernel target, referencing all the source
> files directly(not existing source_sets) and having its own config? Or
> should I create new source sets with different configs? What is the GN way
> to achieve the above?
>
>
>
>
>
> Thanks
>
> Raghu
>
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
I thought it would work to set the defines directly on the vm_kernel
target, but apparently not. The only other way I can think of is to define
a new toolchain, but that's probably worse than just making a copy of the
source_set with the defines you want added. I'm not really a GN expert
though.
On Tue, 16 Feb 2021 at 15:36, Raghu Krishnamurthy via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
>
>
> I'm experimenting with a few things with hafnium tests and had a question
> of
> how(or what is the right way) to achieve the following with the GN build
> system.
>
> I'm using the primary_with_secondaries test, to make a few modifications
> for
> an experiment. I want to be able to compile this test suite in such a way
> that the service_vm1 target(a vm_kernel target) is compiled with a
> different
> set(or additional set) of defines but not service_vm2 or service_vm3. I'm
> looking at the test/vmapi/primary_with_secondaries/services/BUILD.gn file
> for these targets. More concretely, I want service_vm1 to be compiled with
> -DFOO=1 in addition to existing defines and service_vm2/3 to be compiled
> without -DFOO=1.
>
> I cant seem to find a way to force/push down extra defines on the
> source_sets referenced in the deps field at the vm_kernel("service_vm1")
> target. I know the other way(source_sets propagating their configs upwards
> to targets that depend on it through public_configs) is possible but I'd
> effectively like to do the reverse of it.
>
>
>
> Should I just create another vm_kernel target, referencing all the source
> files directly(not existing source_sets) and having its own config? Or
> should I create new source sets with different configs? What is the GN way
> to achieve the above?
>
>
>
>
>
> Thanks
>
> Raghu
>
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
Hi All,
I'm experimenting with a few things with hafnium tests and had a question of
how(or what is the right way) to achieve the following with the GN build
system.
I'm using the primary_with_secondaries test, to make a few modifications for
an experiment. I want to be able to compile this test suite in such a way
that the service_vm1 target(a vm_kernel target) is compiled with a different
set(or additional set) of defines but not service_vm2 or service_vm3. I'm
looking at the test/vmapi/primary_with_secondaries/services/BUILD.gn file
for these targets. More concretely, I want service_vm1 to be compiled with
-DFOO=1 in addition to existing defines and service_vm2/3 to be compiled
without -DFOO=1.
I cant seem to find a way to force/push down extra defines on the
source_sets referenced in the deps field at the vm_kernel("service_vm1")
target. I know the other way(source_sets propagating their configs upwards
to targets that depend on it through public_configs) is possible but I'd
effectively like to do the reverse of it.
Should I just create another vm_kernel target, referencing all the source
files directly(not existing source_sets) and having its own config? Or
should I create new source sets with different configs? What is the GN way
to achieve the above?
Thanks
Raghu
On Fri, 12 Feb 2021 at 10:11, Zongyuan Liu via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> I have been trying to understand the Arm’s FFA by reading Hafnium’s
> implementation, and recently discovered an inconsistency between the
> specification and the implementation regarding the sender’s mode of donated
> pages after an invocation of FFA_MEM_DONATE.
>
> According to item 12.1 of 11.1.1.2 section in
> https://developer.arm.com/documentation/den0077/latest,
>
> 12. If the call executes successfully, the Relayer must:
> 1. Ensure that the state of the memory region in the participating FF-A
> components is observed as follows:
> 1. If the Receiver is a PE endpoint or a SEPID associated with a dependent
> peripheral device, then:
> • Owner-NA for the Owner.
> • !Owner-NA for the Receiver.
>
> the sender(owner) is supposed to still own the pages, which is not the
> case in the implementation(
> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…
> ).
> I don’t know if there is a reason behind this, but I think at least a
> consequence of it is that the sender would be not able to invoke
> FFA_MEM_RECLAIM successfully before the receiver retrieves those pages,
> which implies possible “page leakage” if the receiver refuses to cooperate.
> I also wrote a simple test case in which the sender invokes
> FFA_MEM_RECLAIM right after FFA_MEM_DONATE. As expected, Hafnium returned
> FFA_DENIED(
> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa_memory.c#n…
> ).
>
> If it is indeed a bug, then a simple fix could be removing “|
> MM_MODE_UNOWNED” at line 572.
>
Looks like you might be right, but the fix is not quite so simple. If you
only do that then when the receiver retrieves the memory region then you'll
end up with both the sender and receiver owning it. So you also need to set
the sender state to UNOWNED when the receiver retrieves it, and do so
atomically with the update to the receiver page table. That's going to add
a bunch of extra complexity unfortunately. Feel free to send a patch though!
Hi,
I have been trying to understand the Arm’s FFA by reading Hafnium’s implementation, and recently discovered an inconsistency between the specification and the implementation regarding the sender’s mode of donated pages after an invocation of FFA_MEM_DONATE.
According to item 12.1 of 11.1.1.2 section in https://developer.arm.com/documentation/den0077/latest,
12. If the call executes successfully, the Relayer must:
1. Ensure that the state of the memory region in the participating FF-A components is observed as follows:
1. If the Receiver is a PE endpoint or a SEPID associated with a dependent peripheral device, then:
• Owner-NA for the Owner.
• !Owner-NA for the Receiver.
the sender(owner) is supposed to still own the pages, which is not the case in the implementation(https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src… ).
I don’t know if there is a reason behind this, but I think at least a consequence of it is that the sender would be not able to invoke FFA_MEM_RECLAIM successfully before the receiver retrieves those pages, which implies possible “page leakage” if the receiver refuses to cooperate.
I also wrote a simple test case in which the sender invokes FFA_MEM_RECLAIM right after FFA_MEM_DONATE. As expected, Hafnium returned FFA_DENIED(https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/ffa… ).
If it is indeed a bug, then a simple fix could be removing “| MM_MODE_UNOWNED” at line 572.
Regards,
Zongyuan Liu
On Mon, 4 Jan 2021 at 17:03, Raghu Krishnamurthy via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
> I was going through src/mm.c in the hafnium repo and noticed a couple of
> things that I think are problem:
>
> 1. mm_vm_defrag and mm_defrag, which eventually call mm_ptable_defrag
> appears to be changing page entries into block entries. Per D5.10.1 of ARM
> ARM, this should use break-before-make, but I don't see it being done in
> code. Am I missing where this is done in code, or is there some reason
> break-before-make is not required during defrag(that is not obvious to me
> from code or comments)?
> 2. In mm_replace_entry, line 278
> (https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/mm.c#n278)
> is
> not followed by a DSB + ISB as required by the break-before-make. Without
> the DSB, a load/store that uses a VA translated by the PTE being replaced
> could be reordered before line 278 and fault. Once again, this looks like a
> bug to me but is there some reason that is not obvious due to which it does
> not require barriers?
>
It looks like that code was added in
https://hafnium-review.googlesource.com/c/hafnium/+/3260. Maybe Andrew
Scull or Wedson can comment, if they can remember?
Hi By Yinhua,
Your experiment fails for two main reasons:
1/ you're attempting to load OP-TEE as a normal world VM whereas OP-TEE is a TEE meant to run in TZ secure world.
2/ you're using qemu which is not yet capable of emulating S-EL2. At present, you'd need to use Arm's FVP.
Can you confirm you wish to run OP-TEE as TEE on top of Hafnium in the secure world?
Clearer instructions on how to run OP-TEE as a Secure Partition shall follow in coming days from Arm's platform team.
Regards,
Olivier.
________________________________________
From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of 陈 胤桦 via Hafnium <hafnium(a)lists.trustedfirmware.org>
Sent: 15 January 2021 09:48
To: hafnium(a)lists.trustedfirmware.org
Subject: [Hafnium] load TEE systems(like OPTEE) on hafnium
Hi all :
I follow the "Getting Started" instructions and run linux as the primary VM on hafnium successfully.
Then, I try to load OP-TEE system as a secondary VM on hafnium but fail.
Is there any document which can help me load TEE system on hafnium?
If not, could you give me some guidance and tips?
The following is the efforts I made :
------
1. I write the file "manifest.dts" as follows:
/dts-v1/;
/ {
hypervisor {
compatible = "hafnium,hafnium";
ffa_tee;
vm1 {
debug_name = "primary VM -chenyinhua";
kernel_filename = "vmlinuz";
ramdisk_filename = "initrd.img";
smc_whitelist = <
0x04000000
0x3200ffff
>;
};
vm2 {
debug_name = "secondary VM 1";
kernel_filename = "kernel0";
vcpu_count = <2>;
mem_size = <0x100000>;
smc_whitelist_permissive;
};
};
};
1.
Run prebuilts/linux-x64/dtc/dtc -I dts -O dtb --out-version 17 -o manifest.dtb manifest.dts
2.
Move "manifest.dtb" into "initrd" directory
3.
Follow this blog to build OP-TEE: https://blog.csdn.net/dddddttttt/article/details/80793453, now I can run optee_examples successfully.
4.
In <opentee-root-dir>/optee_os/out/arm/core, copy the file "tee.bin" into <hafnium-root-dir>/initrd
5.
Rename <hafnium-root-dir>/initrd/tee.bin to <hafnium-root-dir>/initrd/kernel0
6.
In <hafnium-root-dir>/initrd/ , run the following command (The linux's vmlinuz and initrd.img are already in the directory)
find . | cpio -o > ../initrd.img
8. In <hafnium-root-dir>, run
qemu-system-aarch64 \
-M virt,gic_version=3 \
-cpu cortex-a57 -nographic -machine virtualization=true \
-kernel out/reference/qemu_aarch64_clang/hafnium.bin \
-initrd initrd.img -append "rdinit=/sbin/init"
9. The result is as follows:
NOTICE: Initialising hafnium
INFO: text: 0x40001000 - 0x4001b000
INFO: rodata: 0x4001b000 - 0x4001f000
INFO: data: 0x4001f000 - 0x400b7000
INFO: Supported bits in physical address: 44
INFO: Stage 2 has 4 page table levels with 1 pages at the root.
INFO: Found PSCI version: 0x2
INFO: Memory range: 0x40000000 - 0x47ffffff
INFO: Ramdisk range: 0x44000000 - 0x45aa8bff
WARNING: Device memory not provided, defaulting to 1 TB.
INFO: Loaded primary VM with 8 vCPUs, entry at 0x40280000.
INFO: Loading VM id 0x2: secondary VM 1.
INFO: Loaded with 2 vCPUs, entry at 0x47f00000.
INFO: Loading VM id 0x3: secondary VM 2.
INFO: Loaded with 4 vCPUs, entry at 0x47d00000.
./qboot.sh: line 5: 3397 Segmentation fault (core dumped) qemu-system-aarch64 -M virt,gic_version=3 -cpu cortex-a57 -nographic -machine virtualization=true -kernel out/reference/qemu_aarch64_clang/hafnium.bin -initrd initrd.img -append "rdinit=/sbin/init"
I appreciate for any possible help!
Thanks.
------
By Yinhua
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
Hi all :
I follow the "Getting Started" instructions and run linux as the primary VM on hafnium successfully.
Then, I try to load OP-TEE system as a secondary VM on hafnium but fail.
Is there any document which can help me load TEE system on hafnium?
If not, could you give me some guidance and tips?
The following is the efforts I made :
------
1. I write the file "manifest.dts" as follows:
/dts-v1/;
/ {
hypervisor {
compatible = "hafnium,hafnium";
ffa_tee;
vm1 {
debug_name = "primary VM -chenyinhua";
kernel_filename = "vmlinuz";
ramdisk_filename = "initrd.img";
smc_whitelist = <
0x04000000
0x3200ffff
>;
};
vm2 {
debug_name = "secondary VM 1";
kernel_filename = "kernel0";
vcpu_count = <2>;
mem_size = <0x100000>;
smc_whitelist_permissive;
};
};
};
1.
Run prebuilts/linux-x64/dtc/dtc -I dts -O dtb --out-version 17 -o manifest.dtb manifest.dts
2.
Move "manifest.dtb" into "initrd" directory
3.
Follow this blog to build OP-TEE: https://blog.csdn.net/dddddttttt/article/details/80793453, now I can run optee_examples successfully.
4.
In <opentee-root-dir>/optee_os/out/arm/core, copy the file "tee.bin" into <hafnium-root-dir>/initrd
5.
Rename <hafnium-root-dir>/initrd/tee.bin to <hafnium-root-dir>/initrd/kernel0
6.
In <hafnium-root-dir>/initrd/ , run the following command (The linux's vmlinuz and initrd.img are already in the directory)
find . | cpio -o > ../initrd.img
8. In <hafnium-root-dir>, run
qemu-system-aarch64 \
-M virt,gic_version=3 \
-cpu cortex-a57 -nographic -machine virtualization=true \
-kernel out/reference/qemu_aarch64_clang/hafnium.bin \
-initrd initrd.img -append "rdinit=/sbin/init"
9. The result is as follows:
NOTICE: Initialising hafnium
INFO: text: 0x40001000 - 0x4001b000
INFO: rodata: 0x4001b000 - 0x4001f000
INFO: data: 0x4001f000 - 0x400b7000
INFO: Supported bits in physical address: 44
INFO: Stage 2 has 4 page table levels with 1 pages at the root.
INFO: Found PSCI version: 0x2
INFO: Memory range: 0x40000000 - 0x47ffffff
INFO: Ramdisk range: 0x44000000 - 0x45aa8bff
WARNING: Device memory not provided, defaulting to 1 TB.
INFO: Loaded primary VM with 8 vCPUs, entry at 0x40280000.
INFO: Loading VM id 0x2: secondary VM 1.
INFO: Loaded with 2 vCPUs, entry at 0x47f00000.
INFO: Loading VM id 0x3: secondary VM 2.
INFO: Loaded with 4 vCPUs, entry at 0x47d00000.
./qboot.sh: line 5: 3397 Segmentation fault (core dumped) qemu-system-aarch64 -M virt,gic_version=3 -cpu cortex-a57 -nographic -machine virtualization=true -kernel out/reference/qemu_aarch64_clang/hafnium.bin -initrd initrd.img -append "rdinit=/sbin/init"
I appreciate for any possible help!
Thanks.
------
By Yinhua
Hi All,
I was going through src/mm.c in the hafnium repo and noticed a couple of
things that I think are problem:
1. mm_vm_defrag and mm_defrag, which eventually call mm_ptable_defrag
appears to be changing page entries into block entries. Per D5.10.1 of ARM
ARM, this should use break-before-make, but I don't see it being done in
code. Am I missing where this is done in code, or is there some reason
break-before-make is not required during defrag(that is not obvious to me
from code or comments)?
2. In mm_replace_entry, line 278
(https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/mm.c#n278) is
not followed by a DSB + ISB as required by the break-before-make. Without
the DSB, a load/store that uses a VA translated by the PTE being replaced
could be reordered before line 278 and fault. Once again, this looks like a
bug to me but is there some reason that is not obvious due to which it does
not require barriers?
Thanks
Raghu
