From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: qemu-kvm: do not allow vcpu stop with in progress PIO Date: Wed, 10 Feb 2010 19:07:49 +0200 Message-ID: <20100210170749.GG2995@redhat.com> References: <20100204213643.GC2766@amt.cnet> <4B6B4031.80008@redhat.com> <20100208224119.GA6516@amt.cnet> <4B710300.7090903@redhat.com> <20100209205805.GA25144@amt.cnet> <4B7259E8.70904@redhat.com> <20100210162523.GD23089@amt.cnet> <4B72E16B.7080704@redhat.com> <4B72E435.6010208@suse.de> <4B72E67A.4060201@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Graf , Marcelo Tosatti , kvm@vger.kernel.org, quintela@redhat.com To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:61692 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754179Ab0BJRHw (ORCPT ); Wed, 10 Feb 2010 12:07:52 -0500 Content-Disposition: inline In-Reply-To: <4B72E67A.4060201@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Feb 10, 2010 at 07:01:46PM +0200, Avi Kivity wrote: > On 02/10/2010 06:52 PM, Alexander Graf wrote: > > > >Hrm, trying to read the thread I'm still somewhat lost. What exactly do > >you want to document? > > > > The problem: if KVM_RUN exits with KVM_EXIT_MMIO or KVM_EXIT_IO, > then the internal state is inconsistent. The instruction is only > half completed, and we need to reissue KVM_RUN to complete it. > > However, if we're migrating, then we don't want to execute any more > guest code. Luckily, if you KVM_RUN with a pending signal, then the > pending mmio or io will be completed, and then, if the pending > signal is unmasked in kvm's signal mask, KVM_RUN will exit > immediately. > Can we be sure that pending signal checking will not be introduces somewhere in ioctl generic code before kvm specific code is called? > I would like to document the fact that the signal check happens > between the mmio completion and guest entry, and the above sequence > as a way to get consistent state after mmio. > > -- > error compiling committee.c: too many arguments to function -- Gleb.