From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oupton@google.com>
Cc: kvmarm@lists.cs.columbia.edu, James Morse <james.morse@arm.com>,
Alexandru Elisei <Alexandru.Elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Andrew Jones <drjones@redhat.com>,
Peter Shier <pshier@google.com>,
Ricardo Koller <ricarkol@google.com>,
Reiji Watanabe <reijiw@google.com>,
Raghavendra Rao Anata <rananta@google.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH v2 06/11] KVM: arm64: Add support for SYSTEM_SUSPEND PSCI call
Date: Fri, 01 Oct 2021 15:02:52 +0100 [thread overview]
Message-ID: <87fstksv03.wl-maz@kernel.org> (raw)
In-Reply-To: <CAOQ_QsjjhTg5usW3DS1P+Uin4ApjvbHwwpmXyEo0bzHe6RGL5g@mail.gmail.com>
On Thu, 30 Sep 2021 18:40:43 +0100,
Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Sep 30, 2021 at 5:29 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > I think there is an additional feature we need, which is to give
> > control back to userspace every time a wake-up condition occurs (I did
> > touch on that in [1]). This would give the opportunity to the VMM to
> > do whatever it needs to perform.
> >
> > A typical use case would be to implement wake-up from certain
> > interrupts only (mask non-wake-up IRQs on suspend request, return to
> > the guest for WFI, wake-up returns to the VMM to restore the previous
> > interrupt configuration, resume).
> >
> > Userspace would be free to clear the suspend state and resume the
> > guest, or to reenter WFI.
>
> Yeah, this is definitely needed for the series.
>
> Just to make sure it's clear, what should the default behavior be if
> userspace doesn't touch state at all and it calls KVM_RUN again? It
> would seem to me that we should resume the guest by default, much like
> we would do for the SUSPEND event exit.
My mental model is that the suspend state is "sticky". Once set, it
stays and the guest doesn't execute any instruction until cleared by
the VMM.
It has the advantage that the VMM always knows the state the vcpu is
in, because that's what it asked for, and the vcpu can't change state
on its own.
It means that the VMM would have to set the vcpu state to 'RUNNABLE'
once it is satisfied that it can be run.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Oliver Upton <oupton@google.com>
Cc: kvm@vger.kernel.org, Peter Shier <pshier@google.com>,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2 06/11] KVM: arm64: Add support for SYSTEM_SUSPEND PSCI call
Date: Fri, 01 Oct 2021 15:02:52 +0100 [thread overview]
Message-ID: <87fstksv03.wl-maz@kernel.org> (raw)
In-Reply-To: <CAOQ_QsjjhTg5usW3DS1P+Uin4ApjvbHwwpmXyEo0bzHe6RGL5g@mail.gmail.com>
On Thu, 30 Sep 2021 18:40:43 +0100,
Oliver Upton <oupton@google.com> wrote:
>
> On Thu, Sep 30, 2021 at 5:29 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > I think there is an additional feature we need, which is to give
> > control back to userspace every time a wake-up condition occurs (I did
> > touch on that in [1]). This would give the opportunity to the VMM to
> > do whatever it needs to perform.
> >
> > A typical use case would be to implement wake-up from certain
> > interrupts only (mask non-wake-up IRQs on suspend request, return to
> > the guest for WFI, wake-up returns to the VMM to restore the previous
> > interrupt configuration, resume).
> >
> > Userspace would be free to clear the suspend state and resume the
> > guest, or to reenter WFI.
>
> Yeah, this is definitely needed for the series.
>
> Just to make sure it's clear, what should the default behavior be if
> userspace doesn't touch state at all and it calls KVM_RUN again? It
> would seem to me that we should resume the guest by default, much like
> we would do for the SUSPEND event exit.
My mental model is that the suspend state is "sticky". Once set, it
stays and the guest doesn't execute any instruction until cleared by
the VMM.
It has the advantage that the VMM always knows the state the vcpu is
in, because that's what it asked for, and the vcpu can't change state
on its own.
It means that the VMM would have to set the vcpu state to 'RUNNABLE'
once it is satisfied that it can be run.
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
next prev parent reply other threads:[~2021-10-01 14:03 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-23 19:15 [PATCH v2 00/11] KVM: arm64: Implement PSCI SYSTEM_SUSPEND support Oliver Upton
2021-09-23 19:15 ` Oliver Upton
2021-09-23 19:16 ` [PATCH v2 01/11] KVM: arm64: Drop unused vcpu param to kvm_psci_valid_affinity() Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-10-01 3:50 ` Reiji Watanabe
2021-10-01 3:50 ` Reiji Watanabe
2021-10-05 13:22 ` Andrew Jones
2021-10-05 13:22 ` Andrew Jones
2021-09-23 19:16 ` [PATCH v2 02/11] KVM: arm64: Clean up SMC64 PSCI filtering for AArch32 guests Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-10-01 3:56 ` Reiji Watanabe
2021-10-01 3:56 ` Reiji Watanabe
2021-10-05 13:23 ` Andrew Jones
2021-10-05 13:23 ` Andrew Jones
2021-09-23 19:16 ` [PATCH v2 03/11] KVM: arm64: Encapsulate reset request logic in a helper function Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-10-01 6:04 ` Reiji Watanabe
2021-10-01 6:04 ` Reiji Watanabe
2021-10-01 16:10 ` Oliver Upton
2021-10-01 16:10 ` Oliver Upton
2021-10-05 13:33 ` Andrew Jones
2021-10-05 13:33 ` Andrew Jones
2021-10-05 15:05 ` Oliver Upton
2021-10-05 15:05 ` Oliver Upton
2021-10-05 19:01 ` Andrew Jones
2021-10-05 19:01 ` Andrew Jones
2021-10-13 4:48 ` Reiji Watanabe
2021-10-13 4:48 ` Reiji Watanabe
2021-10-05 13:35 ` Andrew Jones
2021-10-05 13:35 ` Andrew Jones
2021-09-23 19:16 ` [PATCH v2 04/11] KVM: arm64: Rename the KVM_REQ_SLEEP handler Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-10-05 13:34 ` Andrew Jones
2021-10-05 13:34 ` Andrew Jones
2021-09-23 19:16 ` [PATCH v2 05/11] KVM: arm64: Defer WFI emulation as a requested event Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-09-30 10:50 ` Marc Zyngier
2021-09-30 10:50 ` Marc Zyngier
2021-09-30 17:09 ` Sean Christopherson
2021-09-30 17:09 ` Sean Christopherson
2021-09-30 17:32 ` Oliver Upton
2021-09-30 17:32 ` Oliver Upton
2021-09-30 18:08 ` Sean Christopherson
2021-09-30 18:08 ` Sean Christopherson
2021-09-30 21:57 ` Oliver Upton
2021-09-30 21:57 ` Oliver Upton
2021-10-01 13:57 ` Marc Zyngier
2021-10-01 13:57 ` Marc Zyngier
2021-09-23 19:16 ` [PATCH v2 06/11] KVM: arm64: Add support for SYSTEM_SUSPEND PSCI call Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-09-30 12:29 ` Marc Zyngier
2021-09-30 12:29 ` Marc Zyngier
2021-09-30 17:19 ` Sean Christopherson
2021-09-30 17:19 ` Sean Christopherson
2021-09-30 17:35 ` Oliver Upton
2021-09-30 17:35 ` Oliver Upton
2021-09-30 17:40 ` Oliver Upton
2021-09-30 17:40 ` Oliver Upton
2021-10-01 14:02 ` Marc Zyngier [this message]
2021-10-01 14:02 ` Marc Zyngier
2021-10-05 16:02 ` Oliver Upton
2021-10-05 16:02 ` Oliver Upton
2021-09-23 19:16 ` [PATCH v2 07/11] selftests: KVM: Rename psci_cpu_on_test to psci_test Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-10-05 13:36 ` Andrew Jones
2021-10-05 13:36 ` Andrew Jones
2021-09-23 19:16 ` [PATCH v2 08/11] selftests: KVM: Create helper for making SMCCC calls Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-10-05 13:39 ` Andrew Jones
2021-10-05 13:39 ` Andrew Jones
2021-09-23 19:16 ` [PATCH v2 09/11] selftests: KVM: Use KVM_SET_MP_STATE to power off vCPU in psci_test Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-09-23 19:16 ` [PATCH v2 10/11] selftests: KVM: Refactor psci_test to make it amenable to new tests Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-10-05 13:45 ` Andrew Jones
2021-10-05 13:45 ` Andrew Jones
2021-10-05 14:54 ` Oliver Upton
2021-10-05 14:54 ` Oliver Upton
2021-10-05 19:05 ` Andrew Jones
2021-10-05 19:05 ` Andrew Jones
2021-09-23 19:16 ` [PATCH v2 11/11] selftests: KVM: Test SYSTEM_SUSPEND PSCI call Oliver Upton
2021-09-23 19:16 ` Oliver Upton
2021-10-05 13:49 ` Andrew Jones
2021-10-05 13:49 ` Andrew Jones
2021-10-05 15:07 ` Oliver Upton
2021-10-05 15:07 ` Oliver Upton
2021-09-23 20:15 ` [PATCH v2 00/11] KVM: arm64: Implement PSCI SYSTEM_SUSPEND support Oliver Upton
2021-09-23 20:15 ` Oliver Upton
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=87fstksv03.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=Alexandru.Elisei@arm.com \
--cc=drjones@redhat.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=oupton@google.com \
--cc=pshier@google.com \
--cc=rananta@google.com \
--cc=reijiw@google.com \
--cc=ricarkol@google.com \
--cc=suzuki.poulose@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.