linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 10/11] ARM/ARM64: KVM: Emulate PSCI v0.2 CPU_SUSPEND
Date: Sun, 23 Mar 2014 10:54:13 -0700	[thread overview]
Message-ID: <20140323175413.GF30885@cbox> (raw)
In-Reply-To: <CALrVBksdYsNhWY9fr1PZOqNfmfo3BiLWzy0gGx+6SAATQ-eVwA@mail.gmail.com>

On Sat, Mar 22, 2014 at 10:03:28AM +0530, Anup Patel wrote:
> On 22 March 2014 05:07, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> > On Fri, Mar 21, 2014 at 06:23:33PM +0530, Anup Patel wrote:
> >> This patch adds emulation of PSCI v0.2 CPU_SUSPEND function call for
> >> KVM ARM/ARM64. This is a CPU-level function call which can suspend
> >> current CPU or current CPU cluster. We don't have VCPU clusters in
> >> KVM so for KVM we simply suspend the current VCPU.
> >>
> >> The CPU_SUSPEND emulation is not tested much because currently there
> >> is no CPUIDLE driver in Linux kernel that uses PSCI CPU_SUSPEND. The
> >> PSCI CPU_SUSPEND implementation in ARM64 kernel was tested using a
> >> Simple CPUIDLE driver which is not published due to unstable DT-bindings
> >> for PSCI.
> >> (For more info, http://lwn.net/Articles/574950/)
> >>
> >> Even if we had stable DT-bindings for PSCI and CPUIDLE driver that
> >> uses PSCI CPU_SUSPEND then still we need to define SUSPEND states
> >> for KVM ARM/ARM64.
> >>
> >> Due to this, the CPU_SUSPEND emulation added by this patch only pause
> >> current VCPU and to wakeup a suspended VCPU we need to explicity call
> >> PSCI CPU_ON from Guest.
> >>
> >> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> >> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
> >> ---
> >>  arch/arm/kvm/psci.c |   24 ++++++++++++++++++++----
> >>  1 file changed, 20 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
> >> index 1e85452..e32ad10 100644
> >> --- a/arch/arm/kvm/psci.c
> >> +++ b/arch/arm/kvm/psci.c
> >> @@ -52,6 +52,22 @@ static unsigned long psci_affinity_mask(unsigned long affinity_level)
> >>       return affinity_mask;
> >>  }
> >>
> >> +static unsigned long kvm_psci_vcpu_suspend(struct kvm_vcpu *vcpu)
> >> +{
> >> +     /*
> >> +      * NOTE: Currently, we don't have any wakeup events for KVM
> >> +      * hence VCPU suspend turns-out to be same as VCPU off request.
> >> +      * This means to suspend a VCPU we simply set the pause flag
> >> +      * and update VCPU registers as-per wakeup parameters provided
> >> +      * via r2 & r3 (or x2 & x3).
> >> +      */
> >> +     vcpu->arch.pause = true;
> >> +     *vcpu_pc(vcpu) = *vcpu_reg(vcpu, 2);
> >> +     *vcpu_reg(vcpu, 0) = *vcpu_reg(vcpu, 3);
> >
> > But the spec states in Section 5.1.2 that if Bit[16] StateType == 0,
> > then the entry point and context_id parameters are ignored, because all
> > state is retained for a standby state.
> 
> OK, I will update this accordingly.
> 
> >
> > I think Mark Rutland commented that KVM should define at last interrupts
> > to the CPU as a wakeup event.
> 
> How about using kvm_vcpu_block(vcpu) instead of "vcpu->arch.pause = true"?

You mean if StateType==0 only, or will you always force a shutdown event
to be handled as a suspend event (I believe the spec allows for you to
do so)?  If you are going down this path, please document that clearly
somewhere.

I definitely want to see us using something like kvm_vcpu_block(vcpu)
for suspend requests, but the thing with kvm_vcpu_block() is that a
regular signal to the VCPU thread wakes up that VCPU, which I think we
agreed was fine for the WFI implementation, as it should handle spurious
interrupts as wake up events (which is also how we handle the fact that
any VCPUs in WFI will be woken up when migrated).

But for PSCI CPU_SUSPEND, I'm not sure if that's still a valid
assumption.  Anyone?

> 
> This will make CPU_SUSPEND emulation very similar to WFI emulation.
> 

Yes, I think the PSCI docs suggest this should be the behavior as well.

Thanks,
-Christoffer

  reply	other threads:[~2014-03-23 17:54 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-21 12:53 [PATCH v5 00/11] In-kernel PSCI v0.2 emulation for KVM ARM/ARM64 Anup Patel
2014-03-21 12:53 ` [PATCH v5 01/11] KVM: Add capability to advertise PSCI v0.2 support Anup Patel
2014-03-21 23:22   ` Christoffer Dall
2014-03-22  4:00     ` Anup Patel
2014-03-21 12:53 ` [PATCH v5 02/11] ARM/ARM64: KVM: Add base for PSCI v0.2 emulation Anup Patel
2014-03-21 23:27   ` Christoffer Dall
2014-03-22  4:24     ` Anup Patel
2014-03-23 17:44       ` Christoffer Dall
2014-03-24 13:26         ` Rob Herring
2014-03-26 15:32           ` Ashwin Chaugule
2014-03-26 16:08             ` Rob Herring
2014-03-21 12:53 ` [PATCH v5 03/11] KVM: Documentation: Add info regarding KVM_ARM_VCPU_PSCI_0_2 feature Anup Patel
2014-03-21 12:53 ` [PATCH v5 04/11] ARM/ARM64: KVM: Make kvm_psci_call() return convention more flexible Anup Patel
2014-03-21 12:53 ` [PATCH v5 05/11] KVM: Add KVM_EXIT_SYSTEM_EVENT to user space API header Anup Patel
2014-03-21 12:53 ` [PATCH v5 06/11] ARM/ARM64: KVM: Emulate PSCI v0.2 SYSTEM_OFF and SYSTEM_RESET Anup Patel
2014-03-21 12:53 ` [PATCH v5 07/11] ARM/ARM64: KVM: Emulate PSCI v0.2 AFFINITY_INFO Anup Patel
2014-03-21 12:53 ` [PATCH v5 08/11] ARM/ARM64: KVM: Emulate PSCI v0.2 MIGRATE_INFO_TYPE and related functions Anup Patel
2014-03-21 12:53 ` [PATCH v5 09/11] ARM/ARM64: KVM: Fix CPU_ON emulation for PSCI v0.2 Anup Patel
2014-03-21 23:29   ` Christoffer Dall
2014-03-21 12:53 ` [PATCH v5 10/11] ARM/ARM64: KVM: Emulate PSCI v0.2 CPU_SUSPEND Anup Patel
2014-03-21 23:37   ` Christoffer Dall
2014-03-22  4:33     ` Anup Patel
2014-03-23 17:54       ` Christoffer Dall [this message]
2014-03-21 12:53 ` [PATCH v5 11/11] ARM/ARM64: KVM: Advertise KVM_CAP_ARM_PSCI_0_2 to user space Anup Patel
2014-03-21 23:30   ` Christoffer Dall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140323175413.GF30885@cbox \
    --to=christoffer.dall@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).