From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 4C51D40B37A; Thu, 9 Jul 2026 12:03:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783598605; cv=none; b=h7MorInKh6WAMAVZe3PN6MKszRgFUoSXNUfC7YdgWmS/cTKvNGSBzK6FLNuEk/fLWKgaxaMK2lwoaCVdfDbBtF++heBhHrKs00o/6ZqcNx350FIKjgyG7x5Bb2+rFgw4RB2LFl3ibd7WRxJ9NUPveB4cbuSQrBiXwjI7+HwIB9s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783598605; c=relaxed/simple; bh=shMfedVqhPERDV0gLKVLFBplt2jogxaPjX5gmlYCdZU=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=PbjDBsBSi8CCJPmqZL2HDQNkx6RuWgHFBHZ/xpdN/a9gMTkKzAauw6su6Y//74Fip4yGUDGzvSfObmMdeE/mZ0LEbYFPmNwxh99UMlF6+1b+HD7gByYAiaR4hy9ims0uY+zY3jSPyUFEor0BAui82ez//G+bnZ8VpFPSrVBFdEk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f+liHW8a; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="f+liHW8a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E0981F000E9; Thu, 9 Jul 2026 12:03:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783598594; bh=VMlnZiyXf+hyN61e0c4PtxjdZzI77LLHOZVZ/XjZp40=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=f+liHW8aDX0KQdMRnDgSQj1kAwV8lEW36EU0LZZg0VtqK3EW9gd1Gf9ZvU16qS1Mr xXpsxAbMb/hRwuegurS4uaLVEbn2fVRfS/I0jL//1RZBJulpGxvLOzcvweBrkpxfZW lvh4h87QsVsSGMypeX/ii9BIxgVb7NmoPQviRJ9jmy1e5Xws62/ECrpzdwoBhL3VOf 7zIjPP2P4jn35jtn+W1cmrN1TP61MWZaEqE4mm8RQ2spg1qw630hlXch/an4KM0Kui 2R1XcrABmJSgJn7qt8D4UMBhpoBww3tErHutFVW0foB5S7lp2XP91b0t3Naaqr8lQQ AIh0B+lW6PsAA== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-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 1whnTD-00000003Fqc-3vVi; Thu, 09 Jul 2026 12:03:12 +0000 Date: Thu, 09 Jul 2026 13:04:58 +0100 Message-ID: <87wlv45pxx.wl-maz@kernel.org> From: Marc Zyngier To: Joey Gouly Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Steffen Eiden , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: Re: [PATCH 19/28] KVM: arm64: Make HCR_EL2 a non-VNCR register In-Reply-To: <20260708111832.GA99849@e124191.cambridge.arm.com> References: <20260702160248.1377250-1-maz@kernel.org> <20260702160248.1377250-20-maz@kernel.org> <20260708111832.GA99849@e124191.cambridge.arm.com> 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: kvm@vger.kernel.org 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: joey.gouly@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, seiden@linux.ibm.com, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.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, 08 Jul 2026 12:18:32 +0100, Joey Gouly wrote: > > On Thu, Jul 02, 2026 at 05:02:39PM +0100, Marc Zyngier wrote: > > FEAT_NV3 makes a fundamental change to the architecture, by moving > > guest-initiated HCR_EL2 accesses to the NVHCR_EL2 register. As the > > names suggests, this is HCR_EL2 for a NV guest. > > > > But where do NVHCR_EL2 accesses from a guest go? The are redirected > > to the VNCR page, right where HCR_EL2 is stored in the NV2 case. > > Does it hurt? Good. There's more coming. > > > > The challenge here is to make KVM work seamlessly, without rewriting > > everything. Which implies that things such as __vcpu_sys_reg(HCR_EL2) > > must work, no matter the underlying NV implementation. > > > > A simple way to deal with it is to move HCR_EL2's canonical storage > > outside of VNCR for the vast majority of the KVM code, and only have > > a copy at entry/exit times. Given that we don't really support NV3 > > yet, this is pretty simple. > > > > In the process, advertise NVHCR_EL2 as the register that now holds > > offset 0x78 in the VNCR page. > > > > Signed-off-by: Marc Zyngier > > Reviewed-by: Joey Gouly > > > --- > > arch/arm64/include/asm/kvm_host.h | 3 ++- > > arch/arm64/include/asm/vncr_mapping.h | 2 +- > > arch/arm64/kvm/hyp/vhe/switch.c | 9 +++++++++ > > 3 files changed, 12 insertions(+), 2 deletions(-) > > [...] > > @@ -559,6 +563,11 @@ static void fixup_nv_guest_exit(struct kvm_vcpu *vcpu) > > > > *vcpu_cpsr(vcpu) &= ~(PSR_MODE_MASK | PSR_MODE32_BIT); > > *vcpu_cpsr(vcpu) |= mode; > > + > > + /* Publish the latest HCR_EL2 to the emulation */ > > + hcr = __vcpu_sys_reg(vcpu, NVHCR_EL2); > > My alarm bells went off reading this, because the context (in-memory) seemed > wrong, but I see that patch 23 further modifies this for NV3! Yeah, this patch is strictly about moving HCR_EL2 out of VNCR before any NV3 shenanigans. The guest state is still in the same VNCR location when we're running NV2, only duplicated for the benefit of the rest of the KVM emulation. Thanks, M. -- Jazz isn't dead. It just smells funny.