Re: [PATCH] KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context

On Fri, Feb 27, 2026 at 06:07:44PM +0000, Will Deacon wrote:

On Wed, Feb 25, 2026 at 12:09:56PM +0000, Leo Yan wrote:

quoted

[ + Yabin ]

Thanks for Suzuki's reminding, I should mention that Yabin reported
another lockup issue caused by missing CPU PM support in TRBE driver.

We have a patch series to fix the issue:
https://lore.kernel.org/linux-arm-kernel/20251119-arm_coresight_path_power_management_improvement-v5-16-f615a301ad0b@arm.com/ (local)

Two nits on that series:

1. It seems a bit weird to me for the ETE driver to manage TRFCR but for
   the TRBE driver to manage the other registers

TRFCR_ELx is introduced by FEAT_TRF, which is a separate feature from
TRBE, and it can be used for other sinks (like ETR).  I think this is
the main reason that it is implemented in ETE driver rather than TRBE
driver.

2. Are you sure you don't need to save/restore the TRBE state when
   LIMITR.E is clear? Maybe the driver is fine with that, but I'm worried
   that we could suspend in a half-programmed state and lose some of that
   configuration.

If the TRBLIMITR_EL1.E bit is cleared during the CPU is idle, then the
next time the TRBE trace buffer is re-enabled, trbe_enable_hw() must be
called to reconfigure the TRBE registers (including TRBSR_EL1).

One concern is that after a CPU power cycle, some fields in the TRBE
registers may be in the following state:

  "On a cold reset, this field resets to an architecturally UNKNOWN value."

I will change to always save/restore TRBE state.  Thanks for
suggestions.

quoted

Besides your fix the translation regime issue, I'd also suggest applying
the CoreSight PM patch series to fix lockup caused by CPU idle.

Yes, we definitely need something like that in the android kernel trees.
I've previously bodged a hack into the ETE PM notifiers, but if you have
backports of your series to 6.12, 6.6 and 6.1 then we should merge them
into Android. As it stands, I don't have a TRBE-capable device running
mainline.

Let us first merge the series on the master :)

After that, we can consider backporting (I assume Yabin already has a
plan for this).  I'd be happy to help with backporting to v6.12.
However, I cannot commit to backporting to v6.6 or v6.1 at this stage,
as many dependencies are likely to be involved.

Thanks,
Leo