From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: qemu-kvm: do not allow vcpu stop with in progress PIO Date: Wed, 10 Feb 2010 18:40:11 +0200 Message-ID: <4B72E16B.7080704@redhat.com> References: <20100128190300.414710338@redhat.com> <20100128190411.495771070@redhat.com> <4B6B1D1F.1080701@redhat.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, quintela@redhat.com, Gleb Natapov , Alexander Graf To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:61038 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754373Ab0BJQkZ (ORCPT ); Wed, 10 Feb 2010 11:40:25 -0500 In-Reply-To: <20100210162523.GD23089@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On 02/10/2010 06:25 PM, Marcelo Tosatti wrote: > On Wed, Feb 10, 2010 at 09:02:00AM +0200, Avi Kivity wrote: > >> On 02/09/2010 10:58 PM, Marcelo Tosatti wrote: >> >>> You're right... this should be enough to avoid a stop with uncomplete >>> PIO (and this is what happens for MMIO already). The signal will not >>> be dequeued, so KVM will complete_pio and exit before entering with >>> -EAGAIN. Please review and queue for stable. >>> >>> >> Not right enough. This is very fragile, we depend on the kernel >> noticing the signal after completing pio but before starting >> execution. I don't think we guarantee that. >> > As long as the signal is blocked, we do (and for older kernels too). > I meant, that was not an intentional part of the design, but rather a side effect of the implementation. We can pretend it was all part of a master plan and document it, though. >> Maybe we should turn complete_pio/complete_mmio to an ioctl, so that >> we can control what happens exactly. Or maybe it's simplest to >> document it as a feature and guarantee it. There's some merit in it >> - only guest execution is the nonatomic part, so we only interrupt >> that. >> > Right. So would you like a patch to x86.c to comment on this, on top of > complete_pio / mmio completion? > Documentation/kvm/api.txt. Note it's not x86 specific. Alex, can you check if ppc complies? >>> qemu upstream needs a bit more work. >>> >> Could be as simple as raising a blocked exception that is unmasked >> by kvm, then entering the guest. >> > The vcpu inner loop is not atomic in upstream as it is in qemu-kvm. It > breaks out to process pending events way too easily. > Hmm. We can add an explicit call to KVM_RUN. Note we need to loop there. My 16-byte mmio patches (which never saw the light of day) split 16-byte mmios into two 8-byte mmios issued back to back, and we have to be prepared for that eventuality. -- error compiling committee.c: too many arguments to function