From: Will Deacon <will@kernel.org>
To: James Clark <james.clark@linaro.org>
Cc: Marc Zyngier <maz@kernel.org>,
kvmarm@lists.linux.dev, mark.rutland@arm.com,
linux-arm-kernel@lists.infradead.org,
Oliver Upton <oupton@kernel.org>, Leo Yan <leo.yan@arm.com>,
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 12:26:01 +0000 [thread overview]
Message-ID: <aZReWRme4InoSa8M@willie-the-truck> (raw)
In-Reply-To: <cda4e111-29cc-481c-aee2-811f4178f54b@linaro.org>
On Tue, Feb 17, 2026 at 12:20:14PM +0000, James Clark wrote:
> On 16/02/2026 5:32 pm, Will Deacon wrote:
> > On Mon, Feb 16, 2026 at 02:29:31PM +0000, Marc Zyngier wrote:
> > > And even then, I'm tempted to simply get rid of any sort of
> > > guest-only tracing, given that TRBE is not capable of representing
> > > exceptions that are synthesised by the host, making it the resulting
> > > traces useless.
> >
> > I think that effectively means reverting the series merged from here:
> >
> > https://lore.kernel.org/all/20250106142446.628923-1-james.clark@linaro.org/
> >
> > but then we still need to clear TRBLIMITR_EL1.E.
> >
>
> Removing that series would actually have the effect of turning guest trace
> on in nVHE for non-TRBE sinks. The reason for implementing the filtering was
> to turn guest trace off because a user didn't want to see it.
What I meant was, revert that series and then also ensure that both TRFCR
and TRBLIMITR are always zero while running in the guest. Is that not
sufficient?
Will
next prev parent reply other threads:[~2026-02-17 12:26 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
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 [this message]
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=aZReWRme4InoSa8M@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