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 26C89D1039D for ; Wed, 26 Nov 2025 11:48:04 +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=mSFZUulviyaoo5RrAcQow+apsmYVGXZ37R3m6qPriLM=; b=Ic0glPddMj/ysTDxz0wJckK6DV 0UTFE8JvorkBPYCXXQAxXQ5NLhaoLkfllENLYtVfyhLX3drwRSdclYGylmXT9ac/W7aBUb7Ch3MkO aYj9fcUSwXbsCAbjdkizV/B7BH4qTdZKnB99uoyenW53RWGK2tDv1g5l394hIZeQQoerJnlo+/qKL 1KYCprm5gFJyL7TaLzlT0yQ7flZu1m7wLJ8rGkmXf8Rv9FWXJs2Uy4kHXASwPbxV+X80nCDAg+Cj8 h5I85T5L/5ee/Zqqpo1/D97Qdd+0IhGO8avcXI4FaLA9KFUxxcAJrhfSb61Nn8VhXQ63CsVnwLWQV ddyu7A8Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vOE07-0000000Evo1-1NOy; Wed, 26 Nov 2025 11:47:59 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vOE04-0000000Evna-39lD for linux-arm-kernel@lists.infradead.org; Wed, 26 Nov 2025 11:47:57 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 2935B43FB6; Wed, 26 Nov 2025 11:47:56 +0000 (UTC) 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) 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251126_034756_827648_FDC200FE X-CRM114-Status: GOOD ( 29.58 ) 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 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.