On Wed, Aug 20, 2025 at 11:04:15AM -0500, Andrew Davis via OP-TEE wrote:
On 8/20/25 8:50 AM, Jens Wiklander 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.
Same conclusion we came to last year, we disable it for our(TI) platforms for the same reason[0], to prevent stalling the Linux during OP-TEE ops.
I am unsure why folks choose to fix this problem in a platform specific manner (upstream or downstream) since it's a generic platform agnostic problem. Atleast I should be CCed on the problem report and fix proposed since I added that NS_TIMER_SWITCH=1 for OP-TEE in the first place. Also, this means nobody is able to enable ftrace on NXP and TI platforms until now.
-Sumit