[PATCH 06/16] KVM: Add KVM_EXIT_SYSTEM_EVENT to user space API header

[christoffer.dall@linaro.org (Christoffer Dall)]

On Mon, Sep 01, 2014 at 10:30:17AM +0100, Peter Maydell wrote:
> On 1 September 2014 10:20, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> > On Fri, Aug 29, 2014 at 06:39:09PM +0100, Peter Maydell wrote:
> >> Talking with Ard I realised that there's actually a hole in the
> >> specification of this new ABI. Did we intend these shutdown
> >> and reset exits to be:
> >>  (1) requests from the guest for the shutdown/reset to be
> >>    scheduled in the near future (and we'll continue to execute
> >>    the guest until the shutdown actually happens)
> >>  (2) requests for shutdown/reset right now, with no further
> >>    guest instructions to be executed
> >>
> >> ?
> >>
> >> As currently implemented in QEMU we get behaviour (1),
> >> but I think the kernel PSCI implementation assumes
> >> behaviour (2). Who's right?
> >>
> > For the arm/arm64 use of this API (currently the only one?) the host
> > would not break or anything like that if you keep executing the VM, but
> > the guest will expect that no other instructions are executed after this
> > call.
> 
> Well, if we do that then between QEMU and KVM we've
> violated the PSCI ABI we're supposed to provide, so somebody
> is wrong :-)
> 
> I guess that since the kernel already implements "assume
> userspace won't resume the guest vcpu" the path of least
> resistance is to make userspace follow that.

The thing is that we're not exposing PSCI to user space, we're just
exposing a system event, so it feels a bit weird to rely on user space's
correct interpretation of a more generic API, to correctly implement
PSCI in the kernel.  On the other hand, user space can always break the
guest as it sees fit...

-Christoffer