Hi Raghu,
a fix for hftest.py has been merged:
https://review.trustedfirmware.org/c/hafnium/hafnium/+/12481
addressing the random failures of both-world tests and supporting
connection to telnet ports other than 5000
Cheers,
Federico
____________________________________
> From: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com>
> Sent: 04 August 2021 21:01
> To: Olivier Deprez; 'Raghu Krishnamurthy via Hafnium'
> Subject: RE: [Hafnium] Bug in hftest.py
>
> Thanks Olivier. I've created https://developer.trustedfirmware.org/T955 to
> track. Understood all of this is new. I do have local fixes to get around
> the issue so not a hurry to have a fix merged, but something to consider and
> fix since it will eventually show up.
>
>>> the both worlds test scenario is not 100% stable on my machine
> [RK] Likewise. I've noticed that this is caused by lingering FVP processes.
> Usually I ps -ax | grep for FVP instances, kill and then run tests and I
> never see failures after that. The issue that I faced was that the lingering
> FVP would take up telnet ports and the newly spawned ones use different
> ports(>5004) than what hftest.py expects. It appears that when tests fail,
> we may not be cleaning up/exiting processes properly, but I haven't checked.
> Or the code may be just fine and a ctrl+c leaves those processes lingering.
>
> Thanks
> Raghu
>
> -----Original Message-----
> From: Olivier Deprez <Olivier.Deprez(a)arm.com>
> Sent: Tuesday, August 3, 2021 11:51 PM
> To: 'Raghu Krishnamurthy via Hafnium' <hafnium(a)lists.trustedfirmware.org>;
> raghu.ncstate(a)icloud.com
> Subject: Re: [Hafnium] Bug in hftest.py
>
> Hi Raghu,
>
> Thanks for reporting.
> This part of the test infrastructure (testing the SPMC) is still very fresh
> and requires improvement iterations so please bear with us. Also a reason
> it's not yet part of the automated non-regression with jenkins (as opposed
> to the legacy kokoro/test.sh). For the time being we still mostly rely on
> the TF-A CI for testing on the secure side.
>
> IIUC this change was made to help with the test time as the FVP takes long
> to reload on every test.
> But indeed it might have the side effect you describe.
> So either we revert the FVP reloading on every test.
> Or another (somewhat hackish) possibility is to clear the mentioned
> variables from within the test (or make them part of BSS)?
>
> To be fair, the both worlds test scenario is not 100% stable on my machine
> (for some reason the connection is not always successful between the FVP and
> hftest) hence limiting confidence/robustness of my testing and
> investigations. So I wonder is the scripting is still somewhat a bit
> fragile.
>
> Regards,
> Olivier.
>
> ________________________________________
> From: Hafnium <hafnium-bounces(a)lists.trustedfirmware.org> on behalf of Raghu
> Krishnamurthy via Hafnium <hafnium(a)lists.trustedfirmware.org>
> Sent: 03 August 2021 23:47
> To: 'Raghu Krishnamurthy via Hafnium'
> Subject: [Hafnium] Bug in hftest.py
>
> Hi All,
>
>
>
> Wanted to report to you that commit 18a25f9241f86ba2d637011ff465ce3869e8651b
> in hafnium "appears" broken. The issue with the optimization in this patch
> is that the partition images are not reloaded for each test run, which means
> a previous test could have written data to say SRAM, and the following test
> would use the old values from the previous test, when the same image is
> executed again from SRAM for a following test. This would be a problem for
> pretty much anything in the data section of a partition. In my case, I have
> a counter in the data section of my partition, which does not get reset back
> to its original value.
>
> I've attached a patch to help repro the issue. Fix is to disable the
> optimization or somehow reload the images for each run. This affects only
> "both world" tests.
>
> Let me know if I'm missing something here.
>
>
>
> Apply patch and run timeout --foreground 300s ./test/hftest/hftest.py
> --out_partitions out/reference/secure_aem_v8a_fvp_vm_clang --log
> out/reference/kokoro_log --spmc
> out/reference/secure_aem_v8a_fvp_clang/hafnium.bin --driver=fvp --hypervisor
> out/reference/aem_v8a_fvp_clang/hafnium.bin --partitions_json
> test/vmapi/ffa_secure_partitions/ffa_both_world_partitions_test.json
>
>
>
> The command line is from kokoro/test_spmc.sh.
>
>
>
> Thanks
>
> Raghu
>
>
>
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
Hi Xiangyi Xu
For some reason your email was discarded by mailman, did you miss registering to the list?
See few comments inline [OD]
Regards,
Olivier.
________________________________________
From: xiangyi xu <xuxiangyi666(a)gmail.com>
Sent: 27 November 2021 14:13
To: hafnium(a)lists.trustedfirmware.org
Subject: Virtualising OP-TEE with Hafnium at S-EL2
HI ALL:
I am trying to setup Hafnium environment which loads OP-TEE in Security World and Linux in Normal World. I follow this instruction: https://lists.trustedfirmware.org/pipermail/hafnium/2021-January/000130.html. I can load the OP-TEE test successfully. But the BL33 payload is TF-A-tests example (BL33=../tf-a-tests/build/fvp/debug/tftf.bin). Could you share with us the tutorial to boot linux including the FF-A driver in the NS world while loading OP-TEE with Hafnium S-EL2? The presentation PPT is here: https://static.linaro.org/connect/lvc21/presentations/lvc21-305.pdf.
[OD] The mentioned presentation is in context of the Total Compute platform (as opposed to FVP).
It works great for what you want to do, and you can reproduce by following the user manual:
https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs…
There is also work in progress at Linaro to provide a similar environment using the FVP.
@Jens, are there public instructions on how to build the end to end scenario targeting the FVP incl. Linux, FF-A driver, TF-A, Hafnium, OP-TEE ?
If not, I reckon this is in your mid term roadmap?
Secondly, I can boot Linux with QEMU and Hafnium. But it seems Hafnium only supports NS world partition while using QEMU. Is any instruction to boot OP_TEE in Security world with Hafnium S-EL2. Since, QEMU 6.0 already supports S-EL2. However, I could not compile ATF successfully with SPD=spmd CTX_INCLUDE_EL2_REGS=1 PLAT=qemu ...
[OD] qemu is not 'officially' supported for booting Hafnium at S-EL2. Although I have few changes in progress which may help. This is not a priority from Arm perspective, but let me come back on this.
By following https://teaclave.apache.org/trustzone-sdk-docs/getting-started-with-optee-f… , I can boot Linux in NS and OP-TEE in Trustzone with QEMU, but it doesn't work when I add Hafnium. Thanks!
Xiangyi Xu
