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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CDB4C433F5 for ; Thu, 30 Sep 2021 10:50:26 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 8B6FB619E0 for ; Thu, 30 Sep 2021 10:50:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8B6FB619E0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 088894B0B4; Thu, 30 Sep 2021 06:50:25 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9pbTwdF0YmI; Thu, 30 Sep 2021 06:50:23 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id AA03E4A534; Thu, 30 Sep 2021 06:50:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6D3014A1B0 for ; Thu, 30 Sep 2021 06:50:22 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUP2+wXEhj5q for ; Thu, 30 Sep 2021 06:50:21 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 296F249FE6 for ; Thu, 30 Sep 2021 06:50:21 -0400 (EDT) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 983976120D; Thu, 30 Sep 2021 10:50:18 +0000 (UTC) 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 1mVtdo-00Dxeh-Oj; Thu, 30 Sep 2021 11:50:16 +0100 Date: Thu, 30 Sep 2021 11:50:15 +0100 Message-ID: <878rzetk0o.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Subject: Re: [PATCH v2 05/11] KVM: arm64: Defer WFI emulation as a requested event In-Reply-To: <20210923191610.3814698-6-oupton@google.com> References: <20210923191610.3814698-1-oupton@google.com> <20210923191610.3814698-6-oupton@google.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/27.1 (x86_64-pc-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: oupton@google.com, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, drjones@redhat.com, pshier@google.com, ricarkol@google.com, reijiw@google.com, rananta@google.com, kvm@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 Cc: kvm@vger.kernel.org, Peter Shier , kvmarm@lists.cs.columbia.edu X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Thu, 23 Sep 2021 20:16:04 +0100, Oliver Upton wrote: > > The emulation of WFI-like instructions (WFI, PSCI CPU_SUSPEND) is done > by calling kvm_vcpu_block() directly from the respective exit handlers. > A subsequent change to KVM will allow userspace to request a vCPU be > suspended on the next KVM_RUN, necessitating a deferral mechanism for > WFI emulation. > > Refactor such that there is a single WFI implementation which may be > requested with KVM_REQ_SUSPEND. Request WFI emulation from the > aforementioned handlers by making this request. > > Signed-off-by: Oliver Upton > --- > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/arm.c | 9 +++++++++ > arch/arm64/kvm/handle_exit.c | 3 +-- > arch/arm64/kvm/psci.c | 4 +--- > 4 files changed, 12 insertions(+), 5 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index f8be56d5342b..1beda1189a15 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -47,6 +47,7 @@ > #define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3) > #define KVM_REQ_RELOAD_GICv4 KVM_ARCH_REQ(4) > #define KVM_REQ_RELOAD_PMU KVM_ARCH_REQ(5) > +#define KVM_REQ_SUSPEND KVM_ARCH_REQ(6) > > #define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \ > KVM_DIRTY_LOG_INITIALLY_SET) > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 3d4acd354f94..f1a375648e25 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -670,6 +670,12 @@ static void kvm_vcpu_sleep(struct kvm_vcpu *vcpu) > smp_rmb(); > } > > +static void kvm_vcpu_suspend(struct kvm_vcpu *vcpu) Bike-shed alert: I would really prefer this to have 'wfi' in the function name, because we implement suspend in terms of WFI rather than the other way around. > +{ > + kvm_vcpu_block(vcpu); > + kvm_clear_request(KVM_REQ_UNHALT, vcpu); > +} > + > static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu) > { > return vcpu->arch.target >= 0; > @@ -681,6 +687,9 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu) > if (kvm_check_request(KVM_REQ_SLEEP, vcpu)) > kvm_vcpu_sleep(vcpu); > > + if (kvm_check_request(KVM_REQ_SUSPEND, vcpu)) > + kvm_vcpu_suspend(vcpu); > + > if (kvm_check_request(KVM_REQ_VCPU_RESET, vcpu)) > kvm_reset_vcpu(vcpu); > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > index 275a27368a04..5e5ef9ff4fba 100644 > --- a/arch/arm64/kvm/handle_exit.c > +++ b/arch/arm64/kvm/handle_exit.c > @@ -95,8 +95,7 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu) > } else { > trace_kvm_wfx_arm64(*vcpu_pc(vcpu), false); > vcpu->stat.wfi_exit_stat++; > - kvm_vcpu_block(vcpu); > - kvm_clear_request(KVM_REQ_UNHALT, vcpu); > + kvm_make_request(KVM_REQ_SUSPEND, vcpu); > } > > kvm_incr_pc(vcpu); This is a change in behaviour. At the point where the blocking happens, PC will have already been incremented. I'd rather you don't do that. Instead, make the helper available and call into it directly, preserving the current semantics. It is also likely to clash with Sean's kvm_vcpu_block() rework, but we can work around that. > diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c > index bb59b692998b..d453666ddb83 100644 > --- a/arch/arm64/kvm/psci.c > +++ b/arch/arm64/kvm/psci.c > @@ -46,9 +46,7 @@ static unsigned long kvm_psci_vcpu_suspend(struct kvm_vcpu *vcpu) > * specification (ARM DEN 0022A). This means all suspend states > * for KVM will preserve the register state. > */ > - kvm_vcpu_block(vcpu); > - kvm_clear_request(KVM_REQ_UNHALT, vcpu); > - > + kvm_make_request(KVM_REQ_SUSPEND, vcpu); > return PSCI_RET_SUCCESS; > } I have similar feelings about this one, although things only breaks once you enable NV (SMC is trapped and subject to PC adjustments). Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm