From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH 06/16] KVM: Add KVM_EXIT_SYSTEM_EVENT to user space API
 header
Date: Mon, 1 Sep 2014 11:56:29 +0200
Message-ID: <20140901095629.GF19836@cbox>
References: <1401041942-23471-1-git-send-email-christoffer.dall@linaro.org>
 <1401041942-23471-7-git-send-email-christoffer.dall@linaro.org>
 <CAFEAcA-yWadPiE4v7f-C1-V71=QHYLB=fzC78xhNMnNkVSJAhg@mail.gmail.com>
 <20140901092017.GC19836@cbox>
 <CAFEAcA_S9dHbYVDrkr7X+cTcg-TC0nRWd4zLaUTX2zBjr+TKGQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Gleb Natapov <gleb@kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	kvm-devel <kvm@vger.kernel.org>,
	arm-mail-list <linux-arm-kernel@lists.infradead.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Ashwin Chaugule <ashwin.chaugule@linaro.org>,
	Anup Patel <anup.patel@linaro.org>,
	Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-la0-f41.google.com ([209.85.215.41]:59420 "EHLO
	mail-la0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752207AbaIAJ4X (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 1 Sep 2014 05:56:23 -0400
Received: by mail-la0-f41.google.com with SMTP id gi9so5855754lab.0
        for <kvm@vger.kernel.org>; Mon, 01 Sep 2014 02:56:22 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <CAFEAcA_S9dHbYVDrkr7X+cTcg-TC0nRWd4zLaUTX2zBjr+TKGQ@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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