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 E298EE7716D for ; Thu, 5 Dec 2024 13:33:14 +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=jZ/cXBEc0+WzvIm2fhi1PPLgodnyN9TD2rS5aGEE1SM=; b=lOLIte3MUN5BmYRulwOqIfJI0z 0g9E8qzDVSYTcb8fVLd9Evvsjeo0t8Ez/I+v/68H0pUBfhgauIXcKFoYIveJbUoWjh2pEyKAKuF8r MsfQgXIZfwyMA3qTnxUkWDdLeJD58AeuEKSN67qebKvb85eeqANKuxyiVK/m195t63M33vLvi07mA D50jkuZB26UixDTxWGaMQ+bon5pptOXu4WWiqMZozqzyh2hM5sf6VQQfvLN2OsQzodhz6ormk4U95 mf2+m//a5Ovw+dVv0J6X7ijk0cTUlzVJTp6Q/flXr9H29dR4Zk6vkipUbM6OWWrnXI4ikyzq7IdOH FzdJ0Aag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tJByX-0000000GAop-3uY0; Thu, 05 Dec 2024 13:33:01 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tJBwu-0000000GAHo-3VIM for linux-arm-kernel@lists.infradead.org; Thu, 05 Dec 2024 13:31:22 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 18D5BA43822; Thu, 5 Dec 2024 13:29:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C16C3C4CEDF; Thu, 5 Dec 2024 13:31:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733405479; bh=/sHcCMY3XMr6dLQvSV/4gjcitj8SoTgTdLcl5qToPtk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pRJ8dFzzpRO31xufNa4qCQ45PJFTsPpJ7gPU+o95Wycw1WnpsDXfGTTzJKfO1EPCm HHcEj8gr3dSlgZS289ywqeaHWWyl9wN5XsfP1H6Y01NUQ0K+Fpe4gT6R+VMKFpx1E/ N6z5XwNhnjGFPHWPXDS7ab8Cwdt9g2m6WeJwQgWlCRCRz6B19JUZODjYAH1B0y3JSd HLYAnSq25eyzUKRNnttUim1/hUsAhuLV9nHtCBLndUwi62d8vcz76LoGdmTM1AHsnx om1U3lOkfGesIZxaQA6el1cgQefqCU7wcaprLIvG5XxqRKdWw5r+FtoDgeJMnTkYuH 9Q/dI3N7NglPg== 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 1tJBwr-000pIY-GJ; Thu, 05 Dec 2024 13:31:17 +0000 Date: Thu, 05 Dec 2024 13:31:16 +0000 Message-ID: <86h67itfx7.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, Suzuki K Poulose , Oliver Upton , Zenghui Yu , Bjorn Andersson , Christoffer Dall Subject: Re: [PATCH 06/11] KVM: arm64: nv: Acceletate EL0 counter accesses from hypervisor context In-Reply-To: <20241205120707.GA102570@e124191.cambridge.arm.com> References: <20241202172134.384923-1-maz@kernel.org> <20241202172134.384923-7-maz@kernel.org> <20241205120707.GA102570@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/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: joey.gouly@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, andersson@kernel.org, christoffer.dall@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-20241205_053121_001749_71C7E505 X-CRM114-Status: GOOD ( 31.83 ) 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 Thu, 05 Dec 2024 12:07:07 +0000, Joey Gouly wrote: > > On Mon, Dec 02, 2024 at 05:21:29PM +0000, Marc Zyngier wrote: > > Similarly to handling the physical timer accesses early when FEAT_ECV > > causes a trap, we try to handle the physical counter without returning > > to the general sysreg handling. > > > > More surprisingly, we introduce something similar for the virtual > > counter. Although this isn't necessary yet, it will prove useful on > > systems that have a broken CNTVOFF_EL2 implementation. Yes, they exist. > > > > > Special care is taken to offset reads of the counter with the host's > > CNTPOFF_EL2, as we perform this with TGE clear. > > Can you explain this part a bit more? I'm assuming it's somehow related to the > arch_timer_read_cntpct_el0() call. > > However I think we're at EL2 inside kvm_hyp_handle_timer(), so reading > CNTPCT_EL0 won't involve CNTPOFF_EL2. > > What am I missing/misunderstanding? I think the wording above is particularly misleading, and leads to some bad confusion. Let's go back to basics: we're at host EL2, and handling a trap from guest EL2. Although you are right that CNTPOFF_EL2 doesn't affect a direct read of CNTPCT_EL0 from EL2, we are emulating it as if it was executed from EL1 (guest EL2 being EL1). So any offsetting that would be applied if we were not trapping CNTPCT_EL0 must still be applied. In the case of a read from hypervisor context, this is the VM-wide offset. But this makes me realise that... > > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/hyp/include/hyp/switch.h | 5 +++++ > > arch/arm64/kvm/hyp/vhe/switch.c | 13 +++++++++++++ > > 2 files changed, 18 insertions(+) > > > > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h > > index 34f53707892df..30e572de28749 100644 > > --- a/arch/arm64/kvm/hyp/include/hyp/switch.h > > +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h > > @@ -501,6 +501,11 @@ static inline bool handle_tx2_tvm(struct kvm_vcpu *vcpu) > > return true; > > } > > > > +static inline u64 compute_counter_value(struct arch_timer_context *ctxt) > > +{ > > + return arch_timer_read_cntpct_el0() - timer_get_offset(ctxt); > > +} > > + > > static bool kvm_hyp_handle_cntpct(struct kvm_vcpu *vcpu) > > { > > struct arch_timer_context *ctxt; > > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c > > index b014b0b10bf5d..49815a8a4c9bc 100644 > > --- a/arch/arm64/kvm/hyp/vhe/switch.c > > +++ b/arch/arm64/kvm/hyp/vhe/switch.c > > @@ -296,6 +296,13 @@ static bool kvm_hyp_handle_timer(struct kvm_vcpu *vcpu, u64 *exit_code) > > val = __vcpu_sys_reg(vcpu, CNTP_CVAL_EL0); > > } > > break; > > + case SYS_CNTPCT_EL0: > > + case SYS_CNTPCTSS_EL0: > > + /* If !ELIsInHost(EL0), the guest's CNTPOFF_EL2 applies */ > > + val = compute_counter_value(!(vcpu_el2_e2h_is_set(vcpu) && > > + vcpu_el2_tge_is_set(vcpu)) ? > > + vcpu_ptimer(vcpu) : vcpu_hptimer(vcpu)); ... this should be simplified, because there is no case where we can be in HYP context *and* not be using the hptimer() context (everything else would be handled by kvm_handle_cntxct()). I'm minded to change this to: diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c index a8b1a23712329..5a79ed0aac613 100644 --- a/arch/arm64/kvm/hyp/vhe/switch.c +++ b/arch/arm64/kvm/hyp/vhe/switch.c @@ -305,10 +305,7 @@ static bool kvm_hyp_handle_timer(struct kvm_vcpu *vcpu, u64 *exit_code) break; case SYS_CNTPCT_EL0: case SYS_CNTPCTSS_EL0: - /* If !ELIsInHost(EL0), the guest's CNTPOFF_EL2 applies */ - val = compute_counter_value(!(vcpu_el2_e2h_is_set(vcpu) && - vcpu_el2_tge_is_set(vcpu)) ? - vcpu_ptimer(vcpu) : vcpu_hptimer(vcpu)); + val = compute_counter_value(vcpu_hptimer(vcpu)); break; case SYS_CNTV_CTL_EL02: val = __vcpu_sys_reg(vcpu, CNTV_CTL_EL0); Thanks, M. -- Without deviation from the norm, progress is not possible.