On Mon, Sep 01, 2014 at 10:30:17AM +0100, Peter Maydell wrote: > On 1 September 2014 10:20, Christoffer Dall <christoffer.dall@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
