Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Leo Yan <leo.yan@arm.com>
Cc: James Clark <james.clark@linaro.org>,
	Marc Zyngier <maz@kernel.org>,
	kvmarm@lists.linux.dev, mark.rutland@arm.com,
	linux-arm-kernel@lists.infradead.org,
	Oliver Upton <oupton@kernel.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH] KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context
Date: Tue, 17 Feb 2026 14:52:32 +0000	[thread overview]
Message-ID: <aZSAsC1YI5_lK3e0@willie-the-truck> (raw)
In-Reply-To: <20260217141917.GA136967@e132581.arm.com>

On Tue, Feb 17, 2026 at 02:19:17PM +0000, Leo Yan wrote:
> On Mon, Feb 16, 2026 at 06:14:11PM +0000, Will Deacon wrote:
> 
> [...]
> 
> > > The TRBE driver might do an extra drain here as a workaround. Hard to tell
> > > if it's actually required in this case (seems like probably not) but it
> > > might be worth doing it anyway to avoid hitting the issue. Especially if we
> > > add guest support later where some of the affected registers might start
> > > being used. See:
> > > 
> > >     if (trbe_needs_drain_after_disable(cpudata))
> > >         trbe_drain_buffer();
> > 
> > Oh great, this thing sucks even more than I realised!
> > 
> > But thanks for pointing that out... this is presumably erratum #2064142,
> > but we probably need to look at #2038923 as well :/
> > 
> > I can't find any public documentation for the problems, but based on the
> > kconfig text then I think we care about #2064142 so that the TRBE
> > register writes when restoring the host context are effective and we
> > care about #2038923 to avoid corrupting trace when re-enabling for the
> > host.
> 
> Seems to me, this is correct.
> 
> > 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...

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

Will


  reply	other threads:[~2026-02-17 14:52 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-16 13:09 [PATCH] KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context Will Deacon
2026-02-16 14:29 ` Marc Zyngier
2026-02-16 15:05   ` James Clark
2026-02-16 15:51     ` Marc Zyngier
2026-02-16 16:10       ` James Clark
2026-02-16 16:49         ` Marc Zyngier
2026-02-20 11:42           ` James Clark
2026-02-24 11:19             ` Marc Zyngier
2026-02-20 15:48           ` Leo Yan
2026-02-24 11:22             ` Marc Zyngier
2026-02-16 18:14     ` Will Deacon
2026-02-17 14:19       ` Leo Yan
2026-02-17 14:52         ` Will Deacon [this message]
2026-02-17 19:01           ` Leo Yan
2026-02-19 13:54             ` Will Deacon
2026-02-19 18:58               ` Leo Yan
2026-02-19 19:06                 ` Leo Yan
2026-02-25 12:09                 ` Leo Yan
2026-02-27 18:07                   ` Will Deacon
2026-03-03 10:36                     ` Leo Yan
2026-03-03 10:47                       ` Suzuki K Poulose
2026-02-16 15:53   ` Alexandru Elisei
2026-02-16 17:10     ` Will Deacon
2026-02-17 12:13       ` Will Deacon
2026-02-16 17:32   ` Will Deacon
2026-02-17 12:20     ` James Clark
2026-02-17 12:26       ` Will Deacon
2026-02-17 13:58         ` James Clark
2026-02-16 15:13 ` James Clark
2026-02-16 17:05   ` Will Deacon
2026-02-17  9:18     ` James Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZSAsC1YI5_lK3e0@willie-the-truck \
    --to=will@kernel.org \
    --cc=james.clark@linaro.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=leo.yan@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox