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

[Will Deacon <will@kernel.org>]

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@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.

Will