From patchwork Tue Jan 28 16:17:19 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 13952762 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 9DC18C0218A for ; Tue, 28 Jan 2025 16:29:18 +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-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3IjWmY71vhhvOmpr24LVXSKNDg69joTog2aZSEy45Xc=; b=1A4tCKMBM8T1lbP2EJYsNiqgxF LrxDFVtYKC/FjVv2uvp7u8LrSivI2Egmwj4ltIAQUD5MSmKnAlM2GfDDFjNjwwInV1rHZ9IE7Yh7j x19VHwwC1IV39mGoNW/sXnXU1zcUt6+y/NBz7rlCB1J2mk0G6NsvbTy+u2H81Sqp8lCMFv0wt/T+B htpFindN8y8fwixfIkJrdF4mrDsJw+hwf06DdU88yAS9wTHGV0VO6he7H8D50VtNG2Hq127GoVP7d bHjRs3GfSoiNX5YW+mq8DFB31hIXi7LCeTRh4rvSw0IwArmQpYoncbyLTy9LEGhAWEDPXRxqSaZpH YBT1VLFg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tcoSX-00000005KAI-2inS; Tue, 28 Jan 2025 16:29:05 +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 1tcoHN-00000005IKK-0r7r for linux-arm-kernel@lists.infradead.org; Tue, 28 Jan 2025 16:17:34 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 767B7A40FB9; Tue, 28 Jan 2025 16:15:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08C04C4CEE4; Tue, 28 Jan 2025 16:17:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738081052; bh=zUnsuDJ9SEtgVgV4nZafL+jOte8yEfS+p4rbkLAt0yE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pCPHfq8/4JaM3m/zoL+vzy5pn95OF9kQyR/MCQuHD0ilREtEFVDJ73RHOMUefFGxm 0V2avTc2LFy3toisb+xKCrvI3pCbO7iRZB/VSd8vA9+V+mFQNK6FwggxFH9A7k/sHD tLYit5xJCuL+XPoL8CibKDSA2W1tVXmZLaOrKm+B/yFlVKTOym4WLcjcHH4//YMTvE vvVwtFW9ipb9TV/nyuNEOsAxaPg2X1UWCfcR2DlYw8TBQIblyNDa39Z8TE5cwvuWWP eYY33f2uF2z9pZQ+c1EpzhjDVK0R2zplL5hKaOuZaiurqMnU+R5atz6z9Q8vTsmh7M +q0O+kuOw/yoA== Received: from sofa.misterjones.org ([185.219.108.64] helo=valley-girl.lan) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tcoHJ-00G6bi-U6; Tue, 28 Jan 2025 16:17:30 +0000 From: Marc Zyngier To: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org Cc: Wei-Lin Chang , Volodymyr Babchuk , Dmytro Terletskyi , Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , stable@vger.kernel.org Subject: [PATCH 1/3] KVM: arm64: timer: Always evaluate the need for a soft timer Date: Tue, 28 Jan 2025 16:17:19 +0000 Message-Id: <20250128161721.3279927-2-maz@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20250128161721.3279927-1-maz@kernel.org> References: <20250128161721.3279927-1-maz@kernel.org> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, r09922117@csie.ntu.edu.tw, Volodymyr_Babchuk@epam.com, Dmytro_Terletskyi@epam.com, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, stable@vger.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-20250128_081733_338348_A19A9F76 X-CRM114-Status: GOOD ( 15.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 When updating the interrupt state for an emulated timer, we return early and skip the setup of a soft timer that runs in parallel with the guest. While this is OK if we have set the interrupt pending, it is pretty wrong if the guest moved CVAL into the future. In that case, no timer is armed and the guest can wait for a very long time (it will take a full put/load cycle for the situation to resolve). This is specially visible with EDK2 running at EL2, but still using the EL1 virtual timer, which in that case is fully emulated. Any key-press takes ages to be captured, as there is no UART interrupt and EDK2 relies on polling from a timer... The fix is simply to drop the early return. If the timer interrupt is pending, we will still return early, and otherwise arm the soft timer. Fixes: 4d74ecfa6458b ("KVM: arm64: Don't arm a hrtimer for an already pending timer") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org --- arch/arm64/kvm/arch_timer.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c index d3d243366536c..035e43f5d4f9a 100644 --- a/arch/arm64/kvm/arch_timer.c +++ b/arch/arm64/kvm/arch_timer.c @@ -471,10 +471,8 @@ static void timer_emulate(struct arch_timer_context *ctx) trace_kvm_timer_emulate(ctx, should_fire); - if (should_fire != ctx->irq.level) { + if (should_fire != ctx->irq.level) kvm_timer_update_irq(ctx->vcpu, should_fire, ctx); - return; - } kvm_timer_update_status(ctx, should_fire); From patchwork Tue Jan 28 16:17:20 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 13952766 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 A9320C02190 for ; Tue, 28 Jan 2025 16:32:03 +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-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SdNUpKRa/P3rwD0jNO4fZ2P5b7NNNmPB0fnsmsXmHDI=; b=3rYE1RkcZVAWZ/hQzgmcr7R7xL mYESy4tWGk7vgU9VS+5bcHntr/jM4VB7dpM3unOJ4Y4RoIdpaZJ6S9dy8MXbpAGzFUgP27LAr2xyR 9g65rhB6BY4zQTX3PzZxSJDDR2+fI2GlOrt0TuCXZMihq75vylGmpyU2JKgemSsbvRZBZ9yUo+GOB GlCZHerZ44zekUYVF0Cvc3ZkR/ZNY4ObZPJYclh4s8oCUy4Gfk/A5QN2hYNzYttyykY8GJCNSgVqB /LYKUiJBrpvj7kdiBgofRdtzds0PQY0aJ6k9q8IGgn0FfAeKKxYWFAS/r9M5ajG3DWPmC+6IK+i5B B6aMha6w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tcoVA-00000005KUu-0Xhb; Tue, 28 Jan 2025 16:31:48 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tcoHN-00000005IKJ-0cbT for linux-arm-kernel@lists.infradead.org; Tue, 28 Jan 2025 16:17:35 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 6D82C5C6097; Tue, 28 Jan 2025 16:16:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BFB5C4CEDF; Tue, 28 Jan 2025 16:17:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738081052; bh=PNu3hTn0GvE3wS0oJZaBn6WB6mPAiAa0NyTaE8ZHxk8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lJ0qZBOM0pMf2U4Bl0q4VeWgk16hoV43PhEi5vzpjvwyQoH5E3mbJB/L9MXRW8aEI 7ATzlMHI3Nosq/xtXp3WNMuZ81Hr3aS4lStg/skTluw658AhJJdLE4j5wTU8HPb184 pV+WUSppdpxVvsc540E0rq0BtjxlnXE7GQAJORZIW+A3fl+5hHPlYTGcLW8qkxQNkP Xi0mBWavTLeN3iV09pWpTa8UhiGPN1P1I4JdrGu4DAYnuybw1Cz6DaRGzNQNKLITJu G9Xxg88cYh0Eu1XETI4z+xoK6V3cINFl658CJY1Kr9ja6AU6sENBH0619IA4ftktl9 gX3/4M7PWpdqQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=valley-girl.lan) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tcoHK-00G6bi-6f; Tue, 28 Jan 2025 16:17:30 +0000 From: Marc Zyngier To: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org Cc: Wei-Lin Chang , Volodymyr Babchuk , Dmytro Terletskyi , Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: [PATCH 2/3] KVM: arm64: timer: Correctly handle EL1 timer emulation when !FEAT_ECV Date: Tue, 28 Jan 2025 16:17:20 +0000 Message-Id: <20250128161721.3279927-3-maz@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20250128161721.3279927-1-maz@kernel.org> References: <20250128161721.3279927-1-maz@kernel.org> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, r09922117@csie.ntu.edu.tw, Volodymyr_Babchuk@epam.com, Dmytro_Terletskyi@epam.com, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250128_081733_322126_87DFA8B7 X-CRM114-Status: GOOD ( 18.98 ) 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 Both Wei-Lin Chang and Volodymyr Babchuk report that the way we handle the emulation of EL1 timers with NV is completely wrong, specially in the case of HCR_EL2.E2H==0. There are three problems in about as many lines of code: - With E2H==0, the EL1 timers are overwritten with the EL1 state, while they should actually contain the EL2 state (as per the timer map) - With E2H==1, we run the full EL1 timer emulation even when ECV is present, hiding a bug in timer_emulate() (see previous patch) - The comments are actively misleading, and say all the wrong things. This is only attributable to the code having been initially written for FEAT_NV, hacked up to handle FEAT_NV2 *in parallel*, and vaguely hacked again to be FEAT_NV2 only. Oh, and yours truly being a gold plated idiot. The fix is obvious: just delete most of the E2H==0 code, have a unified handling of the timers (because they really are E2H agnostic), and make sure we don't execute any of that when FEAT_ECV is present. Fixes: 4bad3068cfa9f ("KVM: arm64: nv: Sync nested timer state with FEAT_NV2") Reported-by: Wei-Lin Chang Reported-by: Volodymyr Babchuk Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/fqiqfjzwpgbzdtouu2pwqlu7llhnf5lmy4hzv5vo6ph4v3vyls@jdcfy3fjjc5k Link: https://lore.kernel.org/r/87frl51tse.fsf@epam.com --- arch/arm64/kvm/arch_timer.c | 30 ++++++++++-------------------- 1 file changed, 10 insertions(+), 20 deletions(-) diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c index 035e43f5d4f9a..e59836e0260cf 100644 --- a/arch/arm64/kvm/arch_timer.c +++ b/arch/arm64/kvm/arch_timer.c @@ -974,31 +974,21 @@ void kvm_timer_sync_nested(struct kvm_vcpu *vcpu) * which allows trapping of the timer registers even with NV2. * Still, this is still worse than FEAT_NV on its own. Meh. */ - if (!vcpu_el2_e2h_is_set(vcpu)) { - if (cpus_have_final_cap(ARM64_HAS_ECV)) - return; - - /* - * A non-VHE guest hypervisor doesn't have any direct access - * to its timers: the EL2 registers trap (and the HW is - * fully emulated), while the EL0 registers access memory - * despite the access being notionally direct. Boo. - * - * We update the hardware timer registers with the - * latest value written by the guest to the VNCR page - * and let the hardware take care of the rest. - */ - write_sysreg_el0(__vcpu_sys_reg(vcpu, CNTV_CTL_EL0), SYS_CNTV_CTL); - write_sysreg_el0(__vcpu_sys_reg(vcpu, CNTV_CVAL_EL0), SYS_CNTV_CVAL); - write_sysreg_el0(__vcpu_sys_reg(vcpu, CNTP_CTL_EL0), SYS_CNTP_CTL); - write_sysreg_el0(__vcpu_sys_reg(vcpu, CNTP_CVAL_EL0), SYS_CNTP_CVAL); - } else { + if (!cpus_have_final_cap(ARM64_HAS_ECV)) { /* * For a VHE guest hypervisor, the EL2 state is directly - * stored in the host EL1 timers, while the emulated EL0 + * stored in the host EL1 timers, while the emulated EL1 * state is stored in the VNCR page. The latter could have * been updated behind our back, and we must reset the * emulation of the timers. + * + * A non-VHE guest hypervisor doesn't have any direct access + * to its timers: the EL2 registers trap despite being + * notionally direct (we use the EL1 HW, as for VHE), while + * the EL1 registers access memory. + * + * In both cases, process the emulated timers on each guest + * exit. Boo. */ struct timer_map map; get_timer_map(vcpu, &map); From patchwork Tue Jan 28 16:17:21 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 13952765 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 43542C0218A for ; Tue, 28 Jan 2025 16:30:38 +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-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2+dK8zbVUB+Aun9iZyS6yqEPAydvrbxxLRWm1TkWSTE=; b=l24bkpIZM/0uBvlmOmIWxuD9pz mXX65RvRMvEZa42kVPVwYAZYo9U4NtXAWF5iLxfy5CZjF58d6+wzutRWTwP9T4Vmu/4a3Q2bUx13t 68uzNToCvQj6vUjJTwHiDYdVV6nPQ5XeA15uEl566Z2e5+KfjTkhLlylGsPk5W1rFCJHfzHdUjVB8 bj51qIZasjfEJSbYqY6UONxKPfSq/ZdJ1SLSU004o6qzcIIhJHJc1Dr/GL/rWfQ7wJPztvG3D+weV JNEObEoxwClP15S+tNkp3DD3NF5rgEqsLYm3B1ZBnEBpg55S20Ox5qwDcqAQJh4KSAtYVGVVHwzL6 xA4EKP3w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tcoTq-00000005KHO-1J0s; Tue, 28 Jan 2025 16:30:26 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tcoHN-00000005IKL-0cix for linux-arm-kernel@lists.infradead.org; Tue, 28 Jan 2025 16:17:35 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 824465C6099; Tue, 28 Jan 2025 16:16:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5003FC4CEE3; Tue, 28 Jan 2025 16:17:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738081052; bh=VQtqCF5VwxQZ3zUdT5Ya9xq6VhdkLVv1Fj7Qtdf+K5E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Cw9h1ude8ichfU8pcmw7OAiZfaNagCoGoYZREWS4HpvZEGGI0qDuFO+sQPwwtxy7Q hkgTadm12wz5FNDARPJabzg5QTRWgBQnjELR4unV23s9IaTj+qXeWV709zrRwphqYg Qw5MPLPI9HnZEB2tFYYcLzlg7NvidctOk7EjL1LKDcppNYyw8ghvtwUikpilXaEGUh /q5VOnJCzi3JTJM1mTO1zJU38lqDaqsDwiIQMMcfy32KVjdf5sl6k9zsYc9/8e3ANr h91f/RWl6oM0aYt0Ns3uY06gHtO8ApmbXDc5IuOpY3aWcf3rVu+KMVsLag4rE6K8da /wstY9Vd9s+Ag== Received: from sofa.misterjones.org ([185.219.108.64] helo=valley-girl.lan) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tcoHK-00G6bi-FP; Tue, 28 Jan 2025 16:17:30 +0000 From: Marc Zyngier To: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org Cc: Wei-Lin Chang , Volodymyr Babchuk , Dmytro Terletskyi , Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: [PATCH 3/3] KVM: arm64: timer: Consolidate NV configuration of virtual timers Date: Tue, 28 Jan 2025 16:17:21 +0000 Message-Id: <20250128161721.3279927-4-maz@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20250128161721.3279927-1-maz@kernel.org> References: <20250128161721.3279927-1-maz@kernel.org> MIME-Version: 1.0 X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, r09922117@csie.ntu.edu.tw, Volodymyr_Babchuk@epam.com, Dmytro_Terletskyi@epam.com, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250128_081733_349087_95B74724 X-CRM114-Status: GOOD ( 21.61 ) 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 The way we configure the virtual timers with NV is rather odd: - the EL1 virtual timer gets setup in kvm_timer_vcpu_reset(). Why not? - the EL2 virtual timer gets setup at vcpu_load time, which is really bizarre, because this really should be a one-off. The reason for the second point is that this setup is conditionned on HCR_EL2.E2H, as it decides whether CNTVOFF_EL2 applies to the EL2 virtual counter or not. And of course, this is not known at the point where we reset the timer. Huh. Solve this by introducing a NV-specific init for the timers, matching what we do for the other subsystems, that gets called once we know for sure that the configuration is final (on first vcpu run, effectively). This makes kvm_timer_vcpu_load_nested_switch() slightly simpler. Signed-off-by: Marc Zyngier --- arch/arm64/kvm/arch_timer.c | 48 ++++++++++++++++-------------------- arch/arm64/kvm/arm.c | 3 +++ include/kvm/arm_arch_timer.h | 1 + 3 files changed, 25 insertions(+), 27 deletions(-) diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c index e59836e0260cf..43109277281a7 100644 --- a/arch/arm64/kvm/arch_timer.c +++ b/arch/arm64/kvm/arch_timer.c @@ -759,21 +759,6 @@ static void kvm_timer_vcpu_load_nested_switch(struct kvm_vcpu *vcpu, timer_irq(map->direct_ptimer), &arch_timer_irq_ops); WARN_ON_ONCE(ret); - - /* - * The virtual offset behaviour is "interesting", as it - * always applies when HCR_EL2.E2H==0, but only when - * accessed from EL1 when HCR_EL2.E2H==1. So make sure we - * track E2H when putting the HV timer in "direct" mode. - */ - if (map->direct_vtimer == vcpu_hvtimer(vcpu)) { - struct arch_timer_offset *offs = &map->direct_vtimer->offset; - - if (vcpu_el2_e2h_is_set(vcpu)) - offs->vcpu_offset = NULL; - else - offs->vcpu_offset = &__vcpu_sys_reg(vcpu, CNTVOFF_EL2); - } } } @@ -1045,18 +1030,6 @@ void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu) for (int i = 0; i < nr_timers(vcpu); i++) timer_set_ctl(vcpu_get_timer(vcpu, i), 0); - /* - * A vcpu running at EL2 is in charge of the offset applied to - * the virtual timer, so use the physical VM offset, and point - * the vcpu offset to CNTVOFF_EL2. - */ - if (vcpu_has_nv(vcpu)) { - struct arch_timer_offset *offs = &vcpu_vtimer(vcpu)->offset; - - offs->vcpu_offset = &__vcpu_sys_reg(vcpu, CNTVOFF_EL2); - offs->vm_offset = &vcpu->kvm->arch.timer_data.poffset; - } - if (timer->enabled) { for (int i = 0; i < nr_timers(vcpu); i++) kvm_timer_update_irq(vcpu, false, @@ -1102,6 +1075,27 @@ static void timer_context_init(struct kvm_vcpu *vcpu, int timerid) } } +void kvm_timer_vcpu_nv_init(struct kvm_vcpu *vcpu) +{ + /* + * A vcpu running at EL2 is in charge of the offset applied to + * the virtual timer, so use the physical VM offset, and point + * the vcpu offset to CNTVOFF_EL2. + * + * The virtual offset behaviour is "interesting", as it always + * applies when HCR_EL2.E2H==0, but only when accessed from EL1 when + * HCR_EL2.E2H==1. Apply it to the HV timer when E2H==0. + */ + struct arch_timer_offset *offs = &vcpu_vtimer(vcpu)->offset; + u64 *voff = __ctxt_sys_reg(&vcpu->arch.ctxt, CNTVOFF_EL2); + + offs->vcpu_offset = voff; + offs->vm_offset = &vcpu->kvm->arch.timer_data.poffset; + + if (!vcpu_el2_e2h_is_set(vcpu)) + vcpu_hvtimer(vcpu)->offset.vcpu_offset = voff; +} + void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu) { struct arch_timer_cpu *timer = vcpu_timer(vcpu); diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index 0725a0b50a3e9..deb74ab5775aa 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -815,6 +815,9 @@ int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu) if (ret) return ret; + if (vcpu_has_nv(vcpu)) + kvm_timer_vcpu_nv_init(vcpu); + /* * This needs to happen after any restriction has been applied * to the feature set. diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h index 681cf0c8b9df4..351813133aef6 100644 --- a/include/kvm/arm_arch_timer.h +++ b/include/kvm/arm_arch_timer.h @@ -98,6 +98,7 @@ int __init kvm_timer_hyp_init(bool has_gic); int kvm_timer_enable(struct kvm_vcpu *vcpu); void kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu); void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu); +void kvm_timer_vcpu_nv_init(struct kvm_vcpu *vcpu); void kvm_timer_sync_nested(struct kvm_vcpu *vcpu); void kvm_timer_sync_user(struct kvm_vcpu *vcpu); bool kvm_timer_should_notify_user(struct kvm_vcpu *vcpu);