From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: Reset problem vs. MMIO emulation, hypercalls, etc...
Date: Fri, 3 Aug 2012 14:41:13 -0300
Message-ID: <20120803174113.GA13174@amt.cnet>
References: <1343791031.16975.41.camel@pasglop>
 <501A740F.2000000@redhat.com>
 <1343938818.6911.9.camel@pasglop>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Avi Kivity <avi@redhat.com>, kvm@vger.kernel.org,
	Alexander Graf <agraf@suse.de>,
	Paul Mackerras <paulus@au1.ibm.com>, kvm-ppc@vger.kernel.org
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:28865 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752155Ab2HCSQl (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 3 Aug 2012 14:16:41 -0400
Content-Disposition: inline
In-Reply-To: <1343938818.6911.9.camel@pasglop>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Fri, Aug 03, 2012 at 06:20:18AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2012-08-02 at 15:35 +0300, Avi Kivity wrote:
> > This is actually documented in api.txt, though not in relation to
> > reset:
> > 
> >   NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI, the
> >   corresponding operations are complete (and guest state is
> > consistent)
> >   only after userspace has re-entered the kernel with KVM_RUN.  The
> >   kernel side will first finish incomplete operations and then check
> >   for pending signals.  Userspace can re-enter the guest with an
> >   unmasked signal pending to complete pending operations.
> > 
> > For x86 the issue was with live migration - you can't copy guest
> > register state in the middle of an I/O operation.  Reset is actually
> > similar, but it involves writing state (which can then be overwritten)
> > instead of reading it.
> 
> Hrm, except that doing KVM_RUN with a signal is very cumbersome to do
> and I couldn't quite find the logic in qemu to do it ... but I might
> just have missed it. I can see indeed that in the migration case you
> want to actually complete the operation rather than just "abort it".
> 
> Any chance you can point me to the code that performs that trick qemu
> side for migration ?

kvm-all.c:

        kvm_arch_pre_run(env, run);
        if (env->exit_request) {
            DPRINTF("interrupt exit requested\n");
            /*
             * KVM requires us to reenter the kernel after IO exits to
             * complete
             * instruction emulation. This self-signal will ensure that
             * we
             * leave ASAP again.
             */
            qemu_cpu_kick_self();
        }


> Anthony seems to think that for reset we can just abort the operation
> state in the kernel when the MP state changes.
> 
> Cheers,
> Ben.