linux-kernel - Re: [PATCH] coresight: trbe: Save/restore state across CPU low power state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALJ9ZPPKozzci07i7cqHckBA47gUodH0gymDwFPpW_MJdKWSbA@mail.gmail.com>
Date: Tue, 29 Apr 2025 11:36:25 -0700
From: Yabin Cui <yabinc@...gle.com>
To: Leo Yan <leo.yan@....com>
Cc: Mike Leach <mike.leach@...aro.org>, Anshuman Khandual <anshuman.khandual@....com>, 
	Suzuki K Poulose <suzuki.poulose@....com>, James Clark <james.clark@...aro.org>, 
	Jie Gan <quic_jiegan@...cinc.com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, coresight@...ts.linaro.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] coresight: trbe: Save/restore state across CPU low power state

On Mon, Apr 28, 2025 at 6:05 AM Leo Yan <leo.yan@....com> wrote:
>
> On Mon, Apr 28, 2025 at 01:55:29PM +0100, Mike Leach wrote:
>
> [...]
>
> > > > The TRBE PM can follow the model of the ETE / ETMv4 and save and
> > > > restore if currently in use.
> > >
> > > If TRBE PM is registered as a seperate PM notifier, a prominent issue is
> > > it cannot promise the depedency between ETE and TRBE when execute CPU
> > > power management.  E.g., when entering CPU idle states, ETE should be
> > > disabled prior to switch off TRBE, otherwise, it might cause lockup
> > > issue in hardware.  If ETE and TRBE register PM notifier separately,
> > > we cannot ensure the sequence between ETE and TRBE, this is why we need
> > > to do the operations based on CoreSight paths.
> > >
> >
> > I believe that the architecture requires that if the disabled TRBE
> > cannot receive trace then the ETE should regard the trace as having
> > been output (A1.4 ETE spec). Incorrect sequencing should only result
> > in missing trace, not a core lockup - unless the implementation is not
> > compliant.
>
I tried registering a separate CPU PM notifier for TRBE, but CPU hangs
persisted on Pixel 9, albeit less frequently. After switching to the current
patch, CPU hangs are no longer observed.

I see the line in ETE spec: While all trace outputs are disabled, the trace
unit considers any generated trace data as having been output.
Maybe the enable/disable order issue only happens on some CPU models
or SOCs?  From Android, I hope the coresight driver can solve this issue.
But I'm not sure if ARM has other suggestions.

> Thanks for clarification, Mike.
>
> I would prefer to stick with the CoreSight path approach, as this will
> help us to resolve the issue in a general way - not just for ETE / TRBE
> case, this would be applicable for other types of links and sinks.
>
In my experience, coresight funnels, ETFs, and ETRs don't lose context
with CPU low power state. So probably don't need to disable the whole
coresight path when entering CPU low power state. In Android, I have
a tight project schedule. So I hope this patch is not blocked by refactors.
And I want to backport the patch to previous Android kernel versions. A
fix before refactor is easier to backport.


> Thanks,
> Leo