On Thu, Sep 30, 2021 at 10:19 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Thu, Sep 30, 2021, Marc Zyngier wrote: > > Hi Oliver, > > > > On Thu, 23 Sep 2021 20:16:05 +0100, > > Oliver Upton <oupton@xxxxxxxxxx> wrote: > > > > > > ARM DEN0022D 5.19 "SYSTEM_SUSPEND" describes a PSCI call that may be > > > used to request a system be suspended. This is optional for PSCI v1.0 > > > and to date KVM has elected to not implement the call. However, a > > > VMM/operator may wish to provide their guests with the ability to > > > suspend/resume, necessitating this PSCI call. > > > > > > Implement support for SYSTEM_SUSPEND according to the prescribed > > > behavior in the specification. Add a new system event exit type, > > > KVM_SYSTEM_EVENT_SUSPEND, to notify userspace when a VM has requested a > > > system suspend. Make KVM_MP_STATE_HALTED a valid state on arm64. > > > > KVM_MP_STATE_HALTED is a per-CPU state on x86 (it denotes HLT). Does > > it make really sense to hijack this for something that is more of a > > VM-wide state? I can see that it is tempting to do so as we're using > > the WFI semantics (which are close to HLT's, in a twisted kind of > > way), but I'm also painfully aware that gluing x86 expectations on > > arm64 rarely leads to a palatable result. > > Agreed, we literally have billions of possible KVM_MP_STATE_* values, and I'm pretty > sure all of the existing states are arch-specific. Some are common to multiple > architectures, but I don't think _any_ are common to all architectures. Yeah, I was debating this as well when cooking up the series. No need to overload the x86-ism when we can have a precisely named state for ARM.
