On Thu, Sep 30, 2021 at 11:08 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Thu, Sep 30, 2021, Oliver Upton wrote: > > On Thu, Sep 30, 2021 at 10:09 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > Unlike PSCI power-off, WFI isn't cross-vCPU, thus there's no hard requirement > > > for using a request. And KVM_REQ_SLEEP also has an additional guard in that it > > > doesn't enter rcuwait if power_off (or pause) was cleared after the request was > > > made, e.g. if userspace stuffed vCPU state and set the vCPU RUNNABLE. > > > > Yeah, I don't think the punt is necessary for anything but the case > > where userspace sets the MP state to request WFI behavior. A helper > > method amongst all WFI cases is sufficient, and using the deferral for > > everything is a change in behavior. > > Is there an actual use case for letting userspace request WFI behavior? So for the system event exits we say that userspace can ignore them and call KVM_RUN again. Running the guest after the suspend exit should appear to the guest as though it had resumed. Userspace could do something fancy to handle the suspend (save the VM, wait for an implementation defined event) or ask the kernel to do it. To that end, the MP state is needed to tell KVM to WFI instead of starting the guest immediately.
