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

[Will Deacon]

On Tue, Feb 17, 2026 at 07:01:21PM +0000, Leo Yan wrote:
> On Tue, Feb 17, 2026 at 02:52:32PM +0000, Will Deacon wrote:
> 
> [...]
> 
> > > > It also looks like we can't rely on the dsb(nsh) in the vcpu_run()
> > > > path if that needs to be before the write to TRBLIMITR_EL1.
> > > > 
> > > > In which case, the host->guest something hideous like:
> > > > 
> > > > 	isb();
> > > > 	tsb_csync();	// Executes twice if ARM64_WORKAROUND_TSB_FLUSH_FAILURE!
> > > > 	dsb(nsh);	// I missed this in my patch
> > > > 	write_sysreg_s(0, SYS_TRBLIMITR_EL1);
> > > > 	if (2064142) {
> > > > 		tsb_csync();
> > > > 		dsb(nsh);
> > > > 	}
> > > > 	isb();
> > > 
> > > As I_QXJZX suggests, the section K10.5.10 "Context switching" gives
> > > the flow.  I'd suggest the VM context switch is also aligned to the
> > > description in S_VKHHY.
> > 
> > I honestly have a hard time believing the sequence in S_VKHHY as the DSB
> > seems to be in the wrong place which means the TSB CSYNC can float. It
> > also isn't aligned with what the EL1 driver does...
> 
> Sorry for confusion.  I am checking internally for the flow suggested
> in S_VKHHY.
> 
> > > When switching from host to guest, we need to clear TRCPRGCTLR.EN to
> > > zero.  As the doc states "ETE trace compression logic is stateful,
> > > and disabling the ETE resets this compression state".
> > > 
> > > > and then the guest->host part is:
> > > > 
> > > > 	write_sysreg_s(trblimitr_el1, SYS_TRBLIMITR_EL1);
> > > > 	isb();
> > > > 	if (2038923)
> > > > 		isb();
> > > > 
> > > > Does that look right to you?
> > > 
> > > S_PKLXF gives the flow for switching in.
> > 
> > Well, modulo errata, sure. I don't have access to the errata document so
> > I was more interested in whether I got that right...
> 
> Please see the doc:
> https://developer.arm.com/documentation/SDEN-1873351/1900/?lang=en

Aha, thank you, Leo!

I swear you used to be able to google the erratum number and get the doc,
but that doesn't seem to be the case any more. In fact, if you type the
erratum number into the search box on developer.arm.com it doesn't even
work, so cheers for pointing me to the right place.

Will