From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794426416; b=uu+nQDWpR6EWc/eX8D9rPL32Jm/bi4uWCr/KqlIcSbCttLUA3p1dgedayu4Ctr7PZmR4 LMKmV+rh3HXzS7J4iAO84Yt5TI+HCm9yyFltZxqqptYt+oVF3fWNgcw3FTmV+A5bcmp6J KT0wqe5c+xQX4LMtp3EfXrX05lDwOrd5pvmikOVbjfitLbi56qJh65K+/Q9xMIeEscNFj DgGjGlxeXWfU6BQGActkKz2hOUe6Sqfqg3fBzug/MZpLI0SJY+Sd+rpu/qZsS2UaXgfXH V2I3KGjnHzgkNBTEUgSpZauSktaIu8aLPpQ5K0m50JbPn3FpcXmhzIm//2m39yktoiA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794426416; h=Received:DKIM-Signature:Received:Date:Message-ID:From:To:Cc:Subject: In-Reply-To:References:User-Agent:MIME-Version:Content-Type: X-SA-Exim-Connect-IP:X-SA-Exim-Rcpt-To:X-SA-Exim-Mail-From: X-SA-Exim-Scanned; bh=TEA8Apju+c2xFXRAkFgrvx3sun6rF0Eje/7sHrYH2Vo=; b=k2KAJijxtJ6l0jt/GzwQAwsLy0jMtbs9TvfkuuNzDxvs5utmJf5lA5CtuBXV0IuLEhVt KcbIPDUeYdfboKC+NyGJXDDZ2/GS8r3XhhMJYgDN4lcuTujRY4eX1FzOBl5jlc9XHM0eI svDuB/NIWlpEmzBKVJz6VrEXamTsfBsZw2A8K/lSvILbyGduYor9PbKo7PeF04zca2xeK gqEAdvWVR4Gh8ZC+B6S0HY/W15xYDBfAAAMqY/c5NCD3pE3Ww1uvaV8+QbGT6YvTlIHTW 7hg7SUh5ogwWIiJZA4SekTUfo+RwupqIaIzV7BT76CCmskSs/Xtfl/yVPGLcZO4uoFA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=iCHAVtIZ; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83CB1606A321; Wed, 11 Nov 2026 19:46:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=iCHAVtIZ Received: by smtp.kernel.org (Postfix) with ESMTPSA id 147C61F00A05; Wed, 11 Nov 2026 19:46:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794426416; bh=TEA8Apju+c2xFXRAkFgrvx3sun6rF0Eje/7sHrYH2Vo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=iCHAVtIZhmXIEkCi9XEq5ZvLA0vhBX9/VL11RcUGWxznfbZwW6tuCL26tfzeSXJO1 Qf979tWcOSyzU9sMCyiiCrv3tVOLGIzCBslYE92/Oap7tz4772n7PdhXYAlJnFvaGt 7YXMYq3A2oRDAd4ff+HKEBH/4AjfOmrVlLV31UlYRCNQYfQhZZYEXTkeMVstTsOVvR ZBkxjipDEEpO6IjZk1+AsUXq17W73ZhUfM7RHWH4acrHdJ6oCW1iRoI9jEyPJXoYYe qRXwIQSeO4fpeD33h/lULr3mUSeF+eB+zPPBQ75SjPVCYz82iIlh5gRkgYOUabLxem PcaHUhNHFj16g== 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 1xREHV-0000000ESvo-3uKv; Wed, 11 Nov 2026 19:46:54 +0000 Date: Wed, 11 Nov 2026 19:46:53 +0000 Message-ID: <86ld6z1782.wl-maz@kernel.org> From: Marc Zyngier To: Dan Carpenter Cc: Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Mark Rutland , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, Karthik Bhargavan , =?UTF-8?B?Q2zDqW1lbnQ=?= Blaudeau Subject: Re: [PATCH] KVM: arm64: nv: Initialize hw_mmu to NULL for nested vCPUs In-Reply-To: References: 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) X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list 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: dan@cryspen.com, oupton@kernel.org, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, karthik@pereq.eu, clement@cryspen.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Hi Dan, On Wed, 11 Nov 2026 11:11:19 +0000, Dan Carpenter wrote: > > Before commit 6ded46b5a4fd ("KVM: arm64: nv: Keep reference on stage-2 > MMU when scheduled out"), kvm_vcpu_load_hw_mmu() would set ->hw_mmu on > every load. Now it only sets it when it is set to NULL. > > In kvm_vcpu_init_nested() the vcpu->arch.hw_mmu points to &kvm->arch.mmu > from when it was set in kvm_arch_vcpu_create(). > > Normally what happens next is a two step process. KVM_ARM_VCPU_INIT > calls kvm_reset_vcpu_core() and that sets the vcpu into hyp context > (vEL2). Then KVM_RUN calls kvm_vcpu_load_hw_mmu() which doesn't do > anything. But that is fine because we are in hyp context and the > ->hw_mmu already is pointing to the correct place. > > However if, for example, we are restoring a vcpu that was saved in L2 > context, then the VMM uses KVM_SET_ONE_REG to overwrite the vEL2 state > that kvm_reset_vcpu_core() set up, and the vCPU is in L2 context when > KVM_RUN loads it for the first time. Ideally, kvm_vcpu_load_hw_mmu() > would set the hw_mm to point to L2's page tables but, since is non-NULL, > it leaves it as is. At this point L2 can access L1's memory. Ah, nice one. You can tell how much testing has gone into save/restore... > > Fix this bug but setting ->hw_mmu to NULL in kvm_vcpu_init_nested() so nit: s/but/by/ > that kvm_vcpu_load_hw_mmu() always sets it correctly on the first load. > > Fixes: 6ded46b5a4fd ("KVM: arm64: nv: Keep reference on stage-2 MMU when scheduled out") > Cc: stable@vger.kernel.org > Signed-off-by: Dan Carpenter > --- > arch/arm64/kvm/nested.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c > index 78fa433774c6..60bccb66e52c 100644 > --- a/arch/arm64/kvm/nested.c > +++ b/arch/arm64/kvm/nested.c > @@ -140,6 +140,8 @@ int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu) > kvm->arch.nested_mmus_size += S2_MMU_PER_VCPU; > } > > + vcpu->arch.hw_mmu = NULL; > + I think this really needs a comment to explain why we repaint hw_mmu to NULL, because the next idiot who looks at this (likely me) will probably remove this line... The other thing is that this means that nothing can evaluate vcpu->arch.hw_mmu anywhere outside of the loaded path, as it can be NULL. I *think* this is OK, but I need to really convince myself... I'd like to add something like: /* * We can't rely on the S2 MMU being the canonical one, * as userspace can restore a nested context. Nuke the * hw_mmu early to ensure that we pick the correct one * load time. It also means that we can't rely on hw_mmu * being set to anything useful if the vcpu isn't loaded. */ If that works for you, I'll squash that in. Thanks, M. -- Without deviation from the norm, progress is not possible.