From: Sumit Garg via OP-TEE <op-tee@lists.trustedfirmware.org>
To: Andrew Davis <afd@ti.com>
Cc: op-tee@lists.trustedfirmware.org
Subject: Re: rcu_preempt detected stalls on CPUs/tasks
Date: Thu, 21 Aug 2025 12:38:42 +0530 [thread overview]
Message-ID: <aKbF-gaSYOREE-bA@sumit-X1> (raw)
In-Reply-To: <41817afd-110a-4dd8-b16e-c753347be31f@ti.com>
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
next prev parent reply other threads:[~2025-08-21 7:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-04 17:09 rcu_preempt detected stalls on CPUs/tasks Stauffer Thomas MTANA via OP-TEE
2025-08-20 11:10 ` Jens Wiklander
2025-08-20 12:39 ` Lars Persson
2025-08-20 13:13 ` Jens Wiklander
2025-08-20 13:08 ` Stauffer Thomas MTANA via OP-TEE
2025-08-20 13:50 ` Jens Wiklander
2025-08-20 14:46 ` Jens Wiklander
2025-08-21 9:19 ` Sumit Garg via OP-TEE
2025-08-20 16:04 ` Andrew Davis via OP-TEE
2025-08-21 7:08 ` Sumit Garg via OP-TEE [this message]
2025-08-21 6:42 ` Sumit Garg via OP-TEE
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aKbF-gaSYOREE-bA@sumit-X1 \
--to=op-tee@lists.trustedfirmware.org \
--cc=afd@ti.com \
--cc=sumit.garg@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.