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
next prev parent 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