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

[Will Deacon]

On Mon, Feb 16, 2026 at 05:10:17PM +0000, Will Deacon wrote:
> On Mon, Feb 16, 2026 at 03:53:54PM +0000, Alexandru Elisei wrote:
> > Hi,
> > 
> > On Mon, Feb 16, 2026 at 02:29:31PM +0000, Marc Zyngier wrote:
> > > On Mon, 16 Feb 2026 13:09:59 +0000,
> > > Will Deacon <will at kernel.org> wrote:
> > > > 
> > > > The nVHE world-switch code relies on zeroing TRFCR_EL1 to disable trace
> > > > generation in guest context when self-hosted TRBE is in use by the host.
> > > > 
> > > > Per D3.2.1 ("Controls to prohibit trace at Exception levels"), clearing
> > > > TRFCR_EL1 means that trace generation is prohibited at EL1 and EL0 but
> > > > per R_YCHKJ the Trace Buffer Unit will still be enabled if
> > > > TRBLIMITR_EL1.E is set. R_SJFRQ goes on to state that, when enabled, the
> > > > Trace Buffer Unit can perform address translation for the "owning
> > > > exception level" even when it is out of context.
> > > 
> > > Great. So TRBE violates all the principles that we hold true in the
> > > architecture. Does SPE suffer from the same level of brokenness?
> > 
> > I think not currently - I_JZRDG from DDI0487M.a.a says that after a PSB + DSB
> > 'no new memory accesses using the lower Exception level translation table
> > entries occur'.
> > 
> > But looks like the behaviour will be changed so that it will be similar to TRBE,
> > according to the Arm known issues document [1], added in D23136:
> > 
> > 'When the Profiling Buffer is enabled, profiling is not stopped, and Discard mode
> > is not enabled, the Statistical Profiling Unit might cause speculative
> > translations for the owning translation regime, including when the owning
> > translation regime is out-of-context'.
> 
> I think SPE is ok, as __debug_save_spe() clears PMSCR_EL1 and (unlike
> TRBE) PMSCR_EL1.ExSPE _are_ factored into whether or not profiling is
> "enabled".
> 
> So there's a funny asymmetry between SPE and TRBE, which I assume is due
> to the coresight much associated with the latter.

Urgh...

Alex and I spoke a bit about this on irc and we think SPE might suffer
from the same problem after all. It just uses different terminology, so
it's not as obvious to shake out from the TRBE example.

With TRBE the problem is that we have:

  * TRFCR_EL1 controls whether or not trace generation is "prohibited"

  * TRBLIMITR controls whether or not the trace buffer unit is "enabled"

With SPE we have:

  * PMSCR_EL1 controls whether or not *profiling* is "enabled"

  * PMBLIMITR controls whether or not the *profiling buffer* is "enabled"

Unlike TRBE, the SPE spec doesn't talk concretely about address
translation but I think it's safest to assume that the profiling buffer
being enabled means that it can translate out of context, similarly to
TRBE.

So we'll need to zap PMBLIMITR as well. I'll cook something for v2 but,
as before, I'm going to struggle to test this (I think SPE got whacked
at EL3 for a bunch of errata on the devices I have).

Will