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

Christoffer Dall
2014-09-01T09:56:23Z

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