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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38E42C433EF for ; Thu, 13 Jan 2022 11:43:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230310AbiAMLnq (ORCPT ); Thu, 13 Jan 2022 06:43:46 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:57676 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232071AbiAMLnj (ORCPT ); Thu, 13 Jan 2022 06:43:39 -0500 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 D71E9618AC; Thu, 13 Jan 2022 11:43:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3DE12C36AE9; Thu, 13 Jan 2022 11:43:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642074218; bh=/8LaKwVqFF9NovITOZB13fnjOy0Nhx/4yfON3NuiNOI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=uz75otgv6d17VbkPh9R8NkBXdFApPv/rSl9iXeBVCFFmHv4lrycKN3rYYv9R9jO4q oDkZ786SP8m/thaKLAVwbWOWM+Qn/xqodOxaqyJjCUPifCkWeFjwW0eR9dviMuRBn4 V4aO+tprLNGMZ6+djeRhGycMK4vhwgGlOq5L9pbBf/H48Yw5O/kh3RPPrM9o0V58E0 wUCViunn0/Fj10nyz1FvPd+vQJ8syO9nxg+9TYZwlj+MBCrs8Fbu8WTc/UjGjRHOCs ScSP+CECox3foCMsgjTyEAdyctcaeJHkirjXnIXdJWFXXpZ4OM0a8H/l7QYdnSIqA3 2iN1gLa+GmDqQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n7yVz-000Gdi-Np; Thu, 13 Jan 2022 11:43:35 +0000 Date: Thu, 13 Jan 2022 11:43:30 +0000 Message-ID: <87r19b97z1.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: linux-kernel@vger.kernel.org, aleksandar.qemu.devel@gmail.com, alexandru.elisei@arm.com, anup.patel@wdc.com, aou@eecs.berkeley.edu, atish.patra@wdc.com, benh@kernel.crashing.org, borntraeger@linux.ibm.com, bp@alien8.de, catalin.marinas@arm.com, chenhuacai@kernel.org, dave.hansen@linux.intel.com, david@redhat.com, frankja@linux.ibm.com, frederic@kernel.org, gor@linux.ibm.com, hca@linux.ibm.com, imbrenda@linux.ibm.com, james.morse@arm.com, jmattson@google.com, joro@8bytes.org, kvm@vger.kernel.org, mingo@redhat.com, mpe@ellerman.id.au, nsaenzju@redhat.com, palmer@dabbelt.com, paulmck@kernel.org, paulus@samba.org, paul.walmsley@sifive.com, pbonzini@redhat.com, seanjc@google.com, suzuki.poulose@arm.com, tglx@linutronix.de, tsbogend@alpha.franken.de, vkuznets@redhat.com, wanpengli@tencent.com, will@kernel.org Subject: Re: [PATCH 2/5] kvm/arm64: rework guest entry logic In-Reply-To: References: <20220111153539.2532246-1-mark.rutland@arm.com> <20220111153539.2532246-3-mark.rutland@arm.com> <87tuearwc7.wl-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/27.1 (x86_64-pc-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: mark.rutland@arm.com, linux-kernel@vger.kernel.org, aleksandar.qemu.devel@gmail.com, alexandru.elisei@arm.com, anup.patel@wdc.com, aou@eecs.berkeley.edu, atish.patra@wdc.com, benh@kernel.crashing.org, borntraeger@linux.ibm.com, bp@alien8.de, catalin.marinas@arm.com, chenhuacai@kernel.org, dave.hansen@linux.intel.com, david@redhat.com, frankja@linux.ibm.com, frederic@kernel.org, gor@linux.ibm.com, hca@linux.ibm.com, imbrenda@linux.ibm.com, james.morse@arm.com, jmattson@google.com, joro@8bytes.org, kvm@vger.kernel.org, mingo@redhat.com, mpe@ellerman.id.au, nsaenzju@redhat.com, palmer@dabbelt.com, paulmck@kernel.org, paulus@samba.org, paul.walmsley@sifive.com, pbonzini@redhat.com, seanjc@google.com, suzuki.poulose@arm.com, tglx@linutronix.de, tsbogend@alpha.franken.de, vkuznets@redhat.com, wanpengli@tencent.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 13 Jan 2022 11:17:53 +0000, Mark Rutland wrote: > > On Tue, Jan 11, 2022 at 05:55:20PM +0000, Marc Zyngier wrote: > > On Tue, 11 Jan 2022 15:35:36 +0000, > > Mark Rutland wrote: [...] > > > @@ -891,26 +909,23 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) > > > kvm_arch_vcpu_ctxsync_fp(vcpu); > > > > > > /* > > > - * We may have taken a host interrupt in HYP mode (ie > > > - * while executing the guest). This interrupt is still > > > - * pending, as we haven't serviced it yet! > > > + * We must ensure that any pending interrupts are taken before > > > + * we exit guest timing so that timer ticks are accounted as > > > + * guest time. Transiently unmask interrupts so that any > > > + * pending interrupts are taken. > > > * > > > - * We're now back in SVC mode, with interrupts > > > - * disabled. Enabling the interrupts now will have > > > - * the effect of taking the interrupt again, in SVC > > > - * mode this time. > > > + * Per ARM DDI 0487G.b section D1.13.4, an ISB (or other > > > + * context synchronization event) is necessary to ensure that > > > + * pending interrupts are taken. > > > */ > > > local_irq_enable(); > > > + isb(); > > > + local_irq_disable(); > > > > Small nit: we may be able to elide this enable/isb/disable dance if a > > read of ISR_EL1 returns 0. > > Wouldn't that be broken when using GIC priority masking, since that > can prevent IRQS being signalled ot the PE? You're right. But this can be made even simpler. We already know if we've exited the guest because of an IRQ (ret tells us that), and that's true whether we're using priority masking or not. It could be as simple as: if (ARM_EXCEPTION_CODE(ret) == ARM_EXCEPTION_IRQ) { // We exited because of an interrupt. Let's take // it now to account timer ticks to the guest. local_irq_enable(); isb(); local_irq_disable(); } and that would avoid accounting the interrupt to the guest if it fired after the exit took place. > I'm happy to rework this, but I'll need to think a bit harder about > it. Would you be happy if we did that as a follow-up? Oh, absolutely. I want the flow to be correct before we make it fast(-ish). Thanks, M. -- Without deviation from the norm, progress is not possible.