From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 60367320A0D for ; Wed, 26 Nov 2025 11:47:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764157676; cv=none; b=C+AdZKnKAHuQqDogvgEHQ0m1tEzH+cJu7c/31KQy6TYfhHDU+cEImpGQ0Ri9T4vyhymKsCsnOm/pBK1JPi71TqZ+ePASg+VCasotbfLCEbPCpqYydpB8kTlkLmwtoXGSpCGQl0oWZ2K/iumWqpxf6mRMAlyqEpIne46FJA+PyA8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764157676; c=relaxed/simple; bh=fIQjbi23zkTo/MW8Q5cZnkSIzHfjgtmhtZr1pnvAnlE=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=iJFMFJLZOcGNW+Ve4Uh4u19/22OD3zzZR3w8To+LiTFe5MtMzURoPk1ITFs29uE7YFbpYomN9INmzifP00rszeLRRAWmyMJMHWpTn08b9wkUz6wN+aD4cYJMIsVfch8JwUlGSHVOqFiL/EzApO1IM9Op3ODMcxUDNTuNJw+TYJI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=b6MDnKKC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="b6MDnKKC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01B99C113D0; Wed, 26 Nov 2025 11:47:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764157676; bh=fIQjbi23zkTo/MW8Q5cZnkSIzHfjgtmhtZr1pnvAnlE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=b6MDnKKCd9V+WXMZU+Yrb7YqIUMeXEocsewD0ZufGLRArHEfdeEpJsQ3UjaY9v/Dw 5oflgolSLJ32i0W/NZG17s0DCIwWoujydgUA3jsfZ0x0wCGY5mO27Q8GZbyy1/4ADl oyTYucb5CXYfjArLQLqaRon7+hBiJeq8INAE27qetRmqepnaSp/naZbFh5cTNDEmE1 rCrL4R5pXkU+kcOA3PAbo+F6fD5EADRFCShAGm6HROxmdMb/Y7RA9bKQdW7bDa7T1G sYWj51ahr9vh1T66vk+3myUEGtY323xBgUHCaeELQrz1Sy8HwO6lcfcei3MfJPE3s9 A3CRvNnKSAyJA== 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 1vOE02-00000008ScS-02yA; Wed, 26 Nov 2025 11:47:54 +0000 Date: Wed, 26 Nov 2025 11:47:53 +0000 Message-ID: <865xaxqal2.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, will@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, vladimir.murzin@arm.com Subject: Re: [PATCH v5 2/9] KVM: arm64: Fix Trace Buffer trap polarity for protected VMs In-Reply-To: References: <20251118103807.707500-1-tabba@google.com> <20251118103807.707500-3-tabba@google.com> <868qftqehe.wl-maz@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) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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: tabba@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, will@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, vladimir.murzin@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 26 Nov 2025 10:37:57 +0000, Fuad Tabba wrote: > > Hi Marc, > > On Wed, 26 Nov 2025 at 10:23, Marc Zyngier wrote: > > > > On Tue, 18 Nov 2025 10:37:59 +0000, > > Fuad Tabba wrote: > > > > > > The E2TB bits in MDCR_EL2 control trapping of Trace Buffer system > > > register accesses. These accesses are trapped to EL2 when the bits are > > > clear. > > > > > > The trap initialization logic for protected VMs in pvm_init_traps_mdcr() > > > had the polarity inverted. When a guest did not support the Trace Buffer > > > feature, the code was setting E2TB. This incorrectly disabled the trap, > > > potentially allowing a protected guest to access registers for a feature > > > it was not given. > > > > > > Fix this by inverting the operation. > > > > > > Fixes: f50758260bff ("KVM: arm64: Group setting traps for protected VMs by control register") > > > Signed-off-by: Fuad Tabba > > > --- > > > arch/arm64/kvm/hyp/nvhe/pkvm.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c > > > index 8d06a246dfd1..f6f8996c4f97 100644 > > > --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c > > > +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c > > > @@ -118,7 +118,7 @@ static void pvm_init_traps_mdcr(struct kvm_vcpu *vcpu) > > > val |= MDCR_EL2_TTRF; > > > > > > if (!kvm_has_feat(kvm, ID_AA64DFR0_EL1, TraceBuffer, IMP)) > > > - val |= MDCR_EL2_E2TB_MASK; > > > + val &= ~MDCR_EL2_E2TB_MASK; > > > > This does not only change the trapping logic (bit 24). It also change > > the ownership of the buffer (bit 25). I wonder whether you should do > > something for that, maybe by clearing TRBLIMITR_EL1.E, because > > otherwise, you keep tracing, but using an EL2 VA. What could possibly > > go wrong? > > > > Overall, I'm very uneasy about TRBE in the context of pKVM. > > So should we clear/restore TRBLIMITR_EL1.E on guest entry/exit in > protected mode? I think you need something of the sort, yes. Overall, SPE and TRBE should be aligned on what they are allowed to do, as they are two sides of the same ugly coin. M. -- Without deviation from the norm, progress is not possible.