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

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:

quoted

On Mon, 16 Feb 2026 13:09:59 +0000,
Will Deacon [off-list ref] wrote:

quoted

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