public inbox for op-tee@lists.trustedfirmware.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox