On Wed, Aug 20, 2025 at 04:46:06PM +0200, Jens Wiklander wrote:
FYI, here's the patch https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/42078
Thanks Jens, but as we discussed on review of this patch, I have posted a more complete fix here [1] for OP-TEE ftrace to work along with removing context management of non-secure EL1 physical timer register.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/42085
-Sumit
On Wed, Aug 20, 2025 at 3:50 PM Jens Wiklander jens.wiklander@linaro.org wrote:
Hi Thomas,
On Wed, Aug 20, 2025 at 3:09 PM Stauffer Thomas MTANA via OP-TEE op-tee@lists.trustedfirmware.org wrote:
Hi Jens,
I analyzed this a little bit further since last time I wrote. Here what my "believe" at the moment is
Linux uses the non secure timer in arch_timer (physical/virtual) -> this is correct
OP-TEE uses the secure timer (physical/virtual) -> this is correct
Thanks for confirming.
ARM Trusted Firmware by default enables NS_TIMER_SWITCH=1 with opteed, this IMHO unnecessarily stores/restores time registers, setting NS_TIMER_SWITCH=0 seems to solve the issue, my personal tests and also xtest did not show me any issue so far
All this with some uncertainty, I read through quite some code, but I could have missed a case, where something may go wrong I did not see.
Latencies I tested with cycletest. With NS_TIMER_SWITCH=1 this skyrockets (and explains all the other negative consequences) with NS_TIMER_SWITCH=0, everything is back to normal, even doing "heavy" operation like creating 4096 bit RSA keys with OP-TEE.
This and Lars's findings clearly indicate that we shouldn't set NS_TIMER_SWITCH=1. I'll propose a patch.
Cheers, Jens