On Thu, 30 Sep 2021 18:40:43 +0100, Oliver Upton <oupton@xxxxxxxxxx> wrote: > > On Thu, Sep 30, 2021 at 5:29 AM Marc Zyngier <maz@xxxxxxxxxx> 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.
