public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@arm.com>
To: Will Deacon <will@kernel.org>
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:19:17 +0000	[thread overview]
Message-ID: <20260217141917.GA136967@e132581.arm.com> (raw)
In-Reply-To: <aZNec3B0Iou9PYGw@willie-the-truck>

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.

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.

Thanks,
Leo


  reply	other threads:[~2026-02-17 14:19 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 [this message]
2026-02-17 14:52         ` Will Deacon
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=20260217141917.GA136967@e132581.arm.com \
    --to=leo.yan@arm.com \
    --cc=james.clark@linaro.org \
    --cc=kvmarm@lists.linux.dev \
    --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 \
    --cc=will@kernel.org \
    /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