Re: rcu_preempt detected stalls on CPUs/tasks

[Sumit Garg via OP-TEE <op-tee@lists.trustedfirmware.org>]

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