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.
