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 5FBF9C61DA3 for ; Fri, 24 Feb 2023 09:00:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=6nhdmv2Hsw+2NP7x9oCzEOxZ+NLTi07MhrmQzhPXzdE=; b=A/wjQKOpc3JtWE ow0xyS2xRD3V8W/x31xrCii2DpF3vixrPkM/tByz0No8cjX0YaHCcMfRijfeMF2339l9ha4YyIqFL StXebWcD8BdfBdsJkAZBYXcZOYjUcxsiPcZ+ibrU1gVIK6IKlAJ0CLsGmAH2nacm43PctzkLAUYEW kEF8vFb7aby+DEfKpH5QVNnFj7ybKw59giPXdwtD7XrUBGqUQ7niIAUy2BnT72ERBioyCl0LC63MH ENdm9HDPgMMt4SoHwN9DMyeeiPESwcQyjoKUvHF9d4kUrCX7XW1Y2K3KVOWqml+QbAzk0VZLh+AXd ztcl9/AOcBR4EzvfauWg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pVTvL-001c6e-Cc; Fri, 24 Feb 2023 08:59:27 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pVTvH-001c5V-Ef for linux-arm-kernel@lists.infradead.org; Fri, 24 Feb 2023 08:59:26 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C770C6184D; Fri, 24 Feb 2023 08:59:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32054C433D2; Fri, 24 Feb 2023 08:59:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677229162; bh=11vK/L/5PpDDe6mKxD8lC9D0OP25ipWMak2rzttxd+o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=P4l5HBgMl5WZWBki5KRuxAPlbEqY1Dkb7A9uHsHYEDaKdaMfA+VRYdFf6C2nRis90 T9a7R4tdfpytm+RBUQ8SlbHBWS6Co+hlRQJf3cc+67Vp3i8lzVoLxZMwRlOlfxZl0u E0J5Ou83q6F+3QcrVa6RlTZi6FdSDXZLLr640Gn/BCv7BznLSrWNxxW2lawFSzkaev f8vOhcST9PyHl7X4lXCf1Uoo8fIAkkWV2v86iz66ueXcxz04Hqv+XFVehkqM7uE2FL uUr49itTlg52Zkkt/YclXf6ylsMeBfANnqn8dgnaUO4R6y/MEpHaCO0eRda2tPifZc da3zANEfReImg== 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 1pVTvD-00CqTD-NT; Fri, 24 Feb 2023 08:59:19 +0000 Date: Fri, 24 Feb 2023 08:59:19 +0000 Message-ID: <864jrbxwuw.wl-maz@kernel.org> From: Marc Zyngier To: Colton Lewis Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, ricarkol@google.com, sveith@amazon.de, dwmw2@infradead.org Subject: Re: [PATCH 06/16] KVM: arm64: timers: Use CNTPOFF_EL2 to offset the physical timer In-Reply-To: References: <20230216142123.2638675-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/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: coltonlewis@google.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, ricarkol@google.com, sveith@amazon.de, dwmw2@infradead.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-20230224_005923_579481_DA8A4D59 X-CRM114-Status: GOOD ( 30.57 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 23 Feb 2023 22:34:19 +0000, Colton Lewis wrote: > > > CNTPOFF_EL2 should probably be added to the vcpu_sysreg enum in > kvm_host.h for this patch. This seemed like the most relevant commit. > > Marc Zyngier writes: > > > +static bool has_cntpoff(void) > > +{ > > + return (has_vhe() && cpus_have_final_cap(ARM64_HAS_ECV_CNTPOFF)); > > +} > > + > > This being used to guard the register in set_cntpoff seems to say that > we can only write CNTPOFF in VHE mode. Since it's possible the > underlying hardware could still support CNTPOFF even if KVM is running > in nVHE mode, should there be a way to set CNTPOFF in nVHE mode? Is that > possible? It would have to happen at EL2 (the register is called CNTPOFF_EL2, which should give you a clue). This code execute at EL1 when running nVHE, so any CNTPOFF_EL2 access would UNDEF. > > This caused some confusion for me on my implementation as some teammates > thought so but I could not get an implementation working for nVHE mode. Using CNTPOFF for nVHE is utterly pointless unless you start offloading the host's physical timer to the EL2 physical timer on entry. Otherwise, you completely screw the host timer and everybody dies. > > @@ -84,7 +89,7 @@ u64 timer_get_cval(struct arch_timer_context *ctxt) > > > static u64 timer_get_offset(struct arch_timer_context *ctxt) > > { > > - if (ctxt->offset.vm_offset) > > + if (ctxt && ctxt->offset.vm_offset) > > return *ctxt->offset.vm_offset; > > > return 0; > > nit: this change should be in the previous commit No. I don't even think this is required anymore, due to the way the offset is now handled on the VHE-only path. > > > @@ -480,6 +491,7 @@ static void timer_save_state(struct > > arch_timer_context *ctx) > > write_sysreg_el0(0, SYS_CNTP_CTL); > > isb(); > > > + set_cntpoff(0); > > break; > > case NR_KVM_TIMERS: > > BUG(); > > This seems to say CNTPOFF will be reset to 0 every time a vcpu > switches out. What if the host originally had some value other than 0? > Is KVM responsible for that context? The host never has any value other than zero, just like it doesn't have a value other than 0 for CNTVOFF_EL2. See the comment a few lines above that explain the rationale for CNTVOFF, which mostly applies to CNTPOFF as well. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel