Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp488886pxv; Thu, 1 Jul 2021 02:48:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyH4T1cQ4DyQcm14PTHt/nhRY24Hef5aBHvoNSYAtXlTQNtDS2CVHpnnLNocGzhhNfEogKk X-Received: by 2002:a92:2a05:: with SMTP id r5mr27594456ile.69.1625132909315; Thu, 01 Jul 2021 02:48:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625132909; cv=none; d=google.com; s=arc-20160816; b=D4pu/5UlsyImbLEAIx+wQQK8LS1olu9vpHBotswdUt93rXndOilEpkhKM2h+tQYzpl QsbQ7TctnbNvKs2aQSNsRdM6BbDpCIStT5lCAmjMYs8TkEy2T/T4+NOB4wUJIEBhvAco z5JgpLaCdhBfd3O4vtqtISDNhrOcgiJstAldjP7jWqNKmbQ25U4jj2fLswcFVZa9ItYT p2d00yb9CuQybka4MIIabvqiIUMcY9vCa9z+ujOC3NW7FUWqd5Fc2onRCk1DMrW3tEZG mMS9ZQ9QM3ZtqUq20dD+QVdblTzhhasr9T1ORJxYoIlNWsZLjl6sR+Ffi+eYXxaKd1su NbjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=KxBpDgqk1Ey/xQW5QoMy+bkY1YOpl92uaqUPXrNuvPQ=; b=Xh12eR1zeJ5Nt4fkH54DRu3X5a0aVZuRixl2lIrXP6jcTIZ0/Q27E8xOXW865BhgeJ QefAHb6O01ikPfE35DYe8Kb1MNrHTGP1wJffflYq3Nxzlzb2brA/KeViq84KOiJqsT7d 6/pwPpvOoYaH/wgKRuWaIlAq0/sgeRQWTWE6gIH8j9lbVpWXKoDfCOOVb3VtOZE523Rs ZjUkE4z7yhi1cU02BSuRs9bXrJca+9MiLQzVlj9fbq5YqBc0xx2WZQhet07AlMItZAWw USoEwbFPGg1hzLrIVKAADKRis9JKb0+nW5XCaReZDhMbPbq5fiRP+o7OZrOhWYCiWYTe KQ2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sjwI1qP+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f23si28283959ioo.70.2021.07.01.02.48.16; Thu, 01 Jul 2021 02:48:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sjwI1qP+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235885AbhGAJs0 (ORCPT + 99 others); Thu, 1 Jul 2021 05:48:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235344AbhGAJs0 (ORCPT ); Thu, 1 Jul 2021 05:48:26 -0400 Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64BD7C0617A8 for ; Thu, 1 Jul 2021 02:45:55 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id n99-20020a9d206c0000b029045d4f996e62so5926084ota.4 for ; Thu, 01 Jul 2021 02:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KxBpDgqk1Ey/xQW5QoMy+bkY1YOpl92uaqUPXrNuvPQ=; b=sjwI1qP+JpJtL6HZhO47MI7GrA+78/msovLbbxWqCAi4sh1BvTkCpsP+gBYQQ6s0PA 92NJ8lPGv9A3dj2aO4C7kM5VpuYnl5h/EocekBQ422n/5+hhAlbyatEVs2HVjoaW75GE 4UjeMhBg0r3+20mvMgFt3ozek7fqgGw22H/j8OfVhCXjEDYFHxCwKLLrGKF1GHCaiOvZ U8S8eAJD+BDr/NYjPQAJ3HP+S2LM/W4VT8b927rLRy2Ng0G2xEjGTesrC8/a8qt4QDFr GxiF26a5tnfQfM+QnP5bHzS7kv5CVhp135zVnE3lpo1EUspJGmxl5ioQ1vKXwtB2HIZh Wh/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KxBpDgqk1Ey/xQW5QoMy+bkY1YOpl92uaqUPXrNuvPQ=; b=P9huJqiIO2B9nfRyghF1klAYUa+5c/twmfZujwQYJxVZS7543fsQuF2MM7M7yH2qeL e0t3CRbMcMMNg3/yCbT03NDglcAQPqyaXHf2Zky9OQ2d1SmFUJ6QhAvp1q/Mllmdv4X6 YYK9A/9qiV5J3yjzoyfuixfu2gaILLIczDqLCo/DIVpQLwJ7xI57l320WaH/xwThn/TQ Elo25zF6cxL/OHkMQxpEFN8H63/Mpy/fSMR8WAaiY+L1nn/GkU5OiX9W44FTK4Fsb5AT JbAZdgl5/+D0A74qGHmk40QMkjPr1nugBiY2JcH/x+JJ5O8rMfMw/cDkRnokKS8ROh+B AmLA== X-Gm-Message-State: AOAM533e8EnNLVvEVOsveScldT+e+umZDFt1YQoCPTe9rUkFuHPJB3OF LDzx343AudcHPO04+V9CAV4vA0P84pRK5+YckxkLhg== X-Received: by 2002:a9d:17c5:: with SMTP id j63mr1305084otj.52.1625132754456; Thu, 01 Jul 2021 02:45:54 -0700 (PDT) MIME-Version: 1.0 References: <20210608154805.216869-1-jean-philippe@linaro.org> <20210608154805.216869-3-jean-philippe@linaro.org> In-Reply-To: <20210608154805.216869-3-jean-philippe@linaro.org> From: Fuad Tabba Date: Thu, 1 Jul 2021 10:45:18 +0100 Message-ID: Subject: Re: [RFC PATCH 2/5] KVM: arm64: Move WFI execution to check_vcpu_requests() To: Jean-Philippe Brucker Cc: maz@kernel.org, salil.mehta@huawei.com, lorenzo.pieralisi@arm.com, kvm@vger.kernel.org, corbet@lwn.net, catalin.marinas@arm.com, linux-kernel@vger.kernel.org, will@kernel.org, jonathan.cameron@huawei.com, pbonzini@redhat.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jean-Philippe, On Tue, Jun 8, 2021 at 4:54 PM Jean-Philippe Brucker wrote: > > Prepare for WFI requests from userspace, by adding a suspend request and > moving the WFI execution into check_vcpu_requests(), next to the > power-off logic. > > vcpu->arch.mp_state, previously only RUNNABLE or STOPPED, supports an > additional state HALTED and two new state transitions: > > RUNNABLE -> HALTED from WFI or PSCI CPU_SUSPEND (same vCPU) > HALTED -> RUNNABLE vGIC IRQ, pending timer, signal > > There shouldn't be any functional change with this patch, even though > the KVM_GET_MP_STATE ioctl could now in theory return > KVM_MP_STATE_HALTED, which would break some users' mp_state support. In > practice it should not happen because we do not return to userspace with > HALTED state. Both WFI and PSCI CPU_SUSPEND stay in the vCPU run loop > until the suspend request is consumed. It does feel fragile though, > maybe we should explicitly return RUNNABLE in KVM_GET_MP_STATE in place > of HALTED, to prevent future breakage. It's not really a functional change, but it might introduce some timing/scheduling changes I think. Before your changes, the kvm_vcpu_block() would take place at the end of the vCPU run loop, via handle_exit(). Now it takes place closer to the beginning, after cond_resched() is called, and not if there is a KVM_REQ_IRQ_PENDING. If my observation is correct, would it be good to mention that? Thanks, /fuad > > Signed-off-by: Jean-Philippe Brucker > --- > arch/arm64/include/asm/kvm_host.h | 2 ++ > arch/arm64/kvm/arm.c | 18 ++++++++++++++- > arch/arm64/kvm/handle_exit.c | 3 +-- > arch/arm64/kvm/psci.c | 37 +++++++++++++------------------ > 4 files changed, 35 insertions(+), 25 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index 55a04f4d5919..3ca732feb9a5 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -46,6 +46,7 @@ > #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2) > #define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3) > #define KVM_REQ_RELOAD_GICv4 KVM_ARCH_REQ(4) > +#define KVM_REQ_SUSPEND KVM_ARCH_REQ(5) > > #define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \ > KVM_DIRTY_LOG_INITIALLY_SET) > @@ -722,6 +723,7 @@ int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu, > struct kvm_device_attr *attr); > void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu); > bool kvm_arm_vcpu_is_off(struct kvm_vcpu *vcpu); > +void kvm_arm_vcpu_suspend(struct kvm_vcpu *vcpu); > > /* Guest/host FPSIMD coordination helpers */ > int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu); > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index bcc24adb9c0a..d8cbaa0373c7 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -447,6 +447,12 @@ bool kvm_arm_vcpu_is_off(struct kvm_vcpu *vcpu) > return vcpu->arch.mp_state == KVM_MP_STATE_STOPPED; > } > > +void kvm_arm_vcpu_suspend(struct kvm_vcpu *vcpu) > +{ > + vcpu->arch.mp_state = KVM_MP_STATE_HALTED; > + kvm_make_request(KVM_REQ_SUSPEND, vcpu); > +} > + > int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu, > struct kvm_mp_state *mp_state) > { > @@ -667,6 +673,8 @@ static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu) > > static void check_vcpu_requests(struct kvm_vcpu *vcpu) > { > + bool irq_pending; > + > if (kvm_request_pending(vcpu)) { > if (kvm_check_request(KVM_REQ_SLEEP, vcpu)) > vcpu_req_sleep(vcpu); > @@ -678,7 +686,7 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu) > * Clear IRQ_PENDING requests that were made to guarantee > * that a VCPU sees new virtual interrupts. > */ > - kvm_check_request(KVM_REQ_IRQ_PENDING, vcpu); > + irq_pending = kvm_check_request(KVM_REQ_IRQ_PENDING, vcpu); > > if (kvm_check_request(KVM_REQ_RECORD_STEAL, vcpu)) > kvm_update_stolen_time(vcpu); > @@ -690,6 +698,14 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu) > vgic_v4_load(vcpu); > preempt_enable(); > } > + > + if (kvm_check_request(KVM_REQ_SUSPEND, vcpu)) { > + if (!irq_pending) { > + kvm_vcpu_block(vcpu); > + kvm_clear_request(KVM_REQ_UNHALT, vcpu); > + } > + vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE; > + } > } > } > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > index 6f48336b1d86..9717df3104cf 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_arm_vcpu_suspend(vcpu); > } > > kvm_incr_pc(vcpu); > diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c > index 24b4a2265dbd..42a307ceb95f 100644 > --- a/arch/arm64/kvm/psci.c > +++ b/arch/arm64/kvm/psci.c > @@ -31,27 +31,6 @@ static unsigned long psci_affinity_mask(unsigned long affinity_level) > return 0; > } > > -static unsigned long kvm_psci_vcpu_suspend(struct kvm_vcpu *vcpu) > -{ > - /* > - * NOTE: For simplicity, we make VCPU suspend emulation to be > - * same-as WFI (Wait-for-interrupt) emulation. > - * > - * This means for KVM the wakeup events are interrupts and > - * this is consistent with intended use of StateID as described > - * in section 5.4.1 of PSCI v0.2 specification (ARM DEN 0022A). > - * > - * Further, we also treat power-down request to be same as > - * stand-by request as-per section 5.4.2 clause 3 of PSCI v0.2 > - * 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); > - > - return PSCI_RET_SUCCESS; > -} > - > static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu) > { > struct vcpu_reset_state *reset_state; > @@ -227,7 +206,21 @@ static int kvm_psci_0_2_call(struct kvm_vcpu *vcpu) > break; > case PSCI_0_2_FN_CPU_SUSPEND: > case PSCI_0_2_FN64_CPU_SUSPEND: > - val = kvm_psci_vcpu_suspend(vcpu); > + /* > + * NOTE: For simplicity, we make VCPU suspend emulation to be > + * same-as WFI (Wait-for-interrupt) emulation. > + * > + * This means for KVM the wakeup events are interrupts and this > + * is consistent with intended use of StateID as described in > + * section 5.4.1 of PSCI v0.2 specification (ARM DEN 0022A). > + * > + * Further, we also treat power-down request to be same as > + * stand-by request as-per section 5.4.2 clause 3 of PSCI v0.2 > + * specification (ARM DEN 0022A). This means all suspend states > + * for KVM will preserve the register state. > + */ > + kvm_arm_vcpu_suspend(vcpu); > + val = PSCI_RET_SUCCESS; > break; > case PSCI_0_2_FN_CPU_OFF: > kvm_arm_vcpu_power_off(vcpu); > -- > 2.31.1 > > _______________________________________________ > kvmarm mailing list > kvmarm@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm