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 4CC44D1AD43 for ; Wed, 16 Oct 2024 11:30:47 +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=YM+ytGTYtjh+6Ej7XdqhHvuv93K6GDwhFtpR/rVCOtA=; b=DbWIAX5EagamWPosEqfQh+QGIE LGvwxh0BoVU1bRVO29w+xodyqnkfiRby6ntdS0FpSF1BGjkvyPXJy5GidQxHkaDUtFO6NAvVBw/Q3 fQhyFEaTk0jcK91xCw0XIMYZh2gifykMuIXvp9tk9Ju4D7lE0jW0p8W+fYGVb4u4sFzVaUYb9j5PB 8cLlj3WI/Iy3oOYauPgGe+y/hRsGGhjPhgsChSOblNbYVC+GL47tZ0ZX5E1gP35EMKLfbwg4Rhp6L AI6UZfh4EWcw4kW2Ieg14PmHS+Q1aLsKIj5hacrHRzozecqhrZlwaf5ViYHEzKFKqKqbdDfXz0XIf 2MXh7jrQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t12Ed-0000000Ban0-2nLP; Wed, 16 Oct 2024 11:30:35 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t12DD-0000000BacA-2NMW for linux-arm-kernel@lists.infradead.org; Wed, 16 Oct 2024 11:29:08 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CC6CA5C5BC1; Wed, 16 Oct 2024 11:29:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD5B8C4CEC5; Wed, 16 Oct 2024 11:29:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729078145; bh=cUvNjQmF2c4w0mywk53tMInsr/p3XexjMTpVlyuRhw0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=guNMBDLygehWP+DAab9SyXPikO3EXEcdrtPu1k12TN0haVkd4XgBbH3cVc3ceDnbr MFhbSabp2BSxih6tOO85aR/HaGVQSH0gmQNYrB35OJ98MR4eLtHzkXCKW3q8BeEYlj +Srb8fHnE/nU6KCF+r1WoopAVnsvJqqpvl464T2JwN9TmKc2daHlJT0fhxmSiYaOtJ 1A9eOfvFSCLGaHloah9qMiQ7mkS8hV9yXl8IsaBh+tKqw2WqE5/N16ZqsktCdb0FJb kyKyC8uNeJwjrf7WqOmDJ8E73tVLAC9ihg82/IBQVRY+cNeOaj5DcCCT6pQQzmpb7a ZM8Mdj6O45aQw== 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.95) (envelope-from ) id 1t12D9-0044Cs-37; Wed, 16 Oct 2024 12:29:03 +0100 Date: Wed, 16 Oct 2024 12:29:02 +0100 Message-ID: <861q0g5ls1.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Mark Brown Subject: Re: [PATCH v4 06/36] KVM: arm64: nv: Handle CNTHCTL_EL2 specially In-Reply-To: References: <20241009190019.3222687-1-maz@kernel.org> <20241009190019.3222687-7-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/29.4 (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: alexandru.elisei@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, broonie@kernel.org 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-20241016_042907_715925_440C9163 X-CRM114-Status: GOOD ( 37.35 ) 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, 16 Oct 2024 10:37:18 +0100, Alexandru Elisei wrote: > > Hi Marc, > > I'm planning to have a look at (some) of the patches, do you have a > timeline for merging the series? Just so I know what to prioritise. I want it merged yesterday. All of it. > > On Wed, Oct 09, 2024 at 07:59:49PM +0100, Marc Zyngier wrote: > > Accessing CNTHCTL_EL2 is fraught with danger if running with > > HCR_EL2.E2H=1: half of the bits are held in CNTKCTL_EL1, and > > thus can be changed behind our back, while the rest lives > > in the CNTHCTL_EL2 shadow copy that is memory-based. > > > > Yes, this is a lot of fun! > > > > Make sure that we merge the two on read access, while we can > > write to CNTKCTL_EL1 in a more straightforward manner. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/sys_regs.c | 28 ++++++++++++++++++++++++++++ > > include/kvm/arm_arch_timer.h | 3 +++ > > 2 files changed, 31 insertions(+) > > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index 3cd54656a8e2f..932d2fb7a52a0 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -157,6 +157,21 @@ u64 vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, int reg) > > if (!is_hyp_ctxt(vcpu)) > > goto memory_read; > > > > + /* > > + * CNTHCTL_EL2 requires some special treatment to > > + * account for the bits that can be set via CNTKCTL_EL1. > > + */ > > + switch (reg) { > > + case CNTHCTL_EL2: > > + if (vcpu_el2_e2h_is_set(vcpu)) { > > + val = read_sysreg_el1(SYS_CNTKCTL); > > + val &= CNTKCTL_VALID_BITS; > > + val |= __vcpu_sys_reg(vcpu, reg) & ~CNTKCTL_VALID_BITS; > > + return val; > > + } > > + break; > > + } > > + > > /* > > * If this register does not have an EL1 counterpart, > > * then read the stored EL2 version. > > @@ -207,6 +222,19 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, int reg) > > */ > > __vcpu_sys_reg(vcpu, reg) = val; > > > > + switch (reg) { > > + case CNTHCTL_EL2: > > + /* > > + * If E2H=0, CNHTCTL_EL2 is a pure shadow register. > > + * Otherwise, some of the bits are backed by > > + * CNTKCTL_EL1, while the rest is kept in memory. > > + * Yes, this is fun stuff. > > + */ > > + if (vcpu_el2_e2h_is_set(vcpu)) > > + write_sysreg_el1(val, SYS_CNTKCTL); > > Sorry, but I just can't seem to get my head around why the RES0 bits aren't > cleared. Is KVM relying on the guest to implement Should-Be-Zero-or-Preserved, > as per the RES0 definition? KVM isn't relying on anything. And it isn't about the RES0 bits not being cleared. It is about the HW not providing storage for some of the CNTHCTL_EL2 bits when the guest is using CNTKCTL_EL1 as a proxy for its own view of CNTHCTL_EL2. Namely, bits outside of CNTKCTL_VALID_BITS are not guaranteed to be stored until (IIRC) FEAT_NV2p1, which retrospectively fixes the architecture by mandating that the relevant bits have dedicated storage. M. -- Without deviation from the norm, progress is not possible.