From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C3E11E81A2B for ; Mon, 16 Feb 2026 14:29:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=p8udGX0M0/ZqtCt8bcL/pSf7AtKjCBwii0HAZX5crXY=; b=s8Q3rBHwKejLVHe3p9wEWjnFMk t5moRMzkPApgEU/wqzzVMQ6k5ps/QZ4Azaa82oigk5dO26WkVDQ7o0bcIhEV5K0e4lQOXngCpqSC7 rZMP015A0ZCPmqNb0Ma8p/n/ifLXvFIVRQDB8O9E6gkzTyz2Vf41yTNbJGsnYgcrh/dH+FLQbYzMX b3GTN92ZsdrDwHKbt6T13S6j3xVBOpCyNAXyM+NyA5XgZzxXGJZSzBTNRY4xDPzI7UmwQEScdYdLw QxitsZIuZMjHUCp0r2P1gI9VJNtojdcEiM2Q2hPpuMojwnuyZ15zVMMZW92iKG9Px6NyK3QKSyCNY iRWThSMA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vrzbT-00000006nIC-3CHo; Mon, 16 Feb 2026 14:29:35 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vrzbT-00000006nHw-0UVV for linux-arm-kernel@lists.infradead.org; Mon, 16 Feb 2026 14:29:35 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 3640B600B0; Mon, 16 Feb 2026 14:29:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9858C116C6; Mon, 16 Feb 2026 14:29:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771252173; bh=w34XfjwLQx+Rq/nr250KNuDoMKDvt/wvw7EwiB6Gmfc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DTUm2ZUBkFqEhk/ET8bqKNSTaz/hfmxYYFtKah1NzrOBlxROT+Fr/u6KarkTH+AK5 gecUPTLOGZyX6ZmclWpSsswMemtN7MFeDiWbV0ZOvIFdRxQ1K3tZYnW+4IMi7XzIfG NTKVZN2Un2CbpNHBKrXT50ZEfhZQqiF4UDCWq8YWan+fHGmwlPcM67RAVcNI8uM0aK 62z40Wkmv/OkkXgdPQb/fwUhw+ilChqA+kCsITuZPtJfeE1DqiDaIr2b610SOOcEzU y51ayBBl1GeB8aP4g0Degl1r+ug1JtgIWd9kpYCre2om35OhiHbI+RjWWn0H80TEre oHhJw+jdxdu8g== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vrzbP-0000000BQ0C-1mI6; Mon, 16 Feb 2026 14:29:31 +0000 Date: Mon, 16 Feb 2026 14:29:31 +0000 Message-ID: <86a4x8bw38.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: kvmarm@lists.linux.dev, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, Oliver Upton , James Clark , Leo Yan , Suzuki K Poulose , Fuad Tabba Subject: Re: [PATCH] KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context In-Reply-To: <20260216130959.19317-1-will@kernel.org> References: <20260216130959.19317-1-will@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: will@kernel.org, kvmarm@lists.linux.dev, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, oupton@kernel.org, james.clark@linaro.org, leo.yan@arm.com, suzuki.poulose@arm.com, tabba@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 16 Feb 2026 13:09:59 +0000, Will Deacon wrote: > > The nVHE world-switch code relies on zeroing TRFCR_EL1 to disable trace > generation in guest context when self-hosted TRBE is in use by the host. > > Per D3.2.1 ("Controls to prohibit trace at Exception levels"), clearing > TRFCR_EL1 means that trace generation is prohibited at EL1 and EL0 but > per R_YCHKJ the Trace Buffer Unit will still be enabled if > TRBLIMITR_EL1.E is set. R_SJFRQ goes on to state that, when enabled, the > Trace Buffer Unit can perform address translation for the "owning > exception level" even when it is out of context. Great. So TRBE violates all the principles that we hold true in the architecture. Does SPE suffer from the same level of brokenness? > Consequently, we can end up in a state where TRBE performs speculative > page-table walks for a host VA/IPA in guest/hypervisor context depending > on the value of MDCR_EL2.E2TB, which changes over world-switch. The > result appears to be a heady mixture of data corruption and hardware > lockups. > > Extend the TRBE world-switch code to clear TRBLIMITR_EL1.E after > draining the buffer, restoring the register on return to the host. > > Cc: Marc Zyngier > Cc: Oliver Upton > Cc: James Clark > Cc: Leo Yan > Cc: Suzuki K Poulose > Cc: Fuad Tabba > Fixes: a1319260bf62 ("arm64: KVM: Enable access to TRBE support for host") > Signed-off-by: Will Deacon > --- > > NOTE: This is *untested* as I don't have a TRBE-capable device that can > run upstream but I noticed this by inspection when triaging occasional > hardware lockups on systems using a 6.12-based kernel with TRBE running > at the same time as a vCPU is loaded. This code has changed quite a bit > over time, so stable backports are not entirely straightforward. > Hopefully James/Leo/Suzuki can help us test if folks agree with the > general approach taken here. > > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/hyp/nvhe/debug-sr.c | 36 ++++++++++++++++++++++-------- > 2 files changed, 28 insertions(+), 9 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index ac7f970c7883..a932cf043b83 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -746,6 +746,7 @@ struct kvm_host_data { > u64 pmscr_el1; > /* Self-hosted trace */ > u64 trfcr_el1; > + u64 trblimitr_el1; > /* Values of trap registers for the host before guest entry. */ > u64 mdcr_el2; > u64 brbcr_el1; > diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c > index 2a1c0f49792b..fd389a26bc59 100644 > --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c > +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c > @@ -57,12 +57,27 @@ static void __trace_do_switch(u64 *saved_trfcr, u64 new_trfcr) > write_sysreg_el1(new_trfcr, SYS_TRFCR); > } > > -static bool __trace_needs_drain(void) > +static void __trace_drain_and_disable(void) > { > - if (is_protected_kvm_enabled() && host_data_test_flag(HAS_TRBE)) > - return read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_EL1_E; > + u64 *trblimitr_el1 = host_data_ptr(host_debug_state.trblimitr_el1); > > - return host_data_test_flag(TRBE_ENABLED); > + *trblimitr_el1 = 0; > + > + if (is_protected_kvm_enabled()) { > + if (!host_data_test_flag(HAS_TRBE)) > + return; > + } else { > + if (!host_data_test_flag(TRBE_ENABLED)) > + return; > + } > + > + *trblimitr_el1 = read_sysreg_s(SYS_TRBLIMITR_EL1); > + if (*trblimitr_el1 & TRBLIMITR_EL1_E) { > + isb(); > + tsb_csync(); > + write_sysreg_s(0, SYS_TRBLIMITR_EL1); > + isb(); > + } Doesn't this mean we should be able to get rid of most of the TRFCR messing about that litters the entry/exit code and leave that to VHE only? 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'm still trying to get my hands on a TRBE-enabled system that has some actual firmware tables (my O6 seems to have the HW, but no description of the required coresight infra). Thanks, M. -- Without deviation from the norm, progress is not possible.