From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: qemu-kvm: do not allow vcpu stop with in progress PIO
Date: Wed, 10 Feb 2010 14:25:23 -0200
Message-ID: <20100210162523.GD23089@amt.cnet>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kvm@vger.kernel.org, quintela@redhat.com,
	Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:30787 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754695Ab0BJQ0j (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 10 Feb 2010 11:26:39 -0500
Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1AGQceP028719
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <kvm@vger.kernel.org>; Wed, 10 Feb 2010 11:26:38 -0500
Content-Disposition: inline
In-Reply-To: <4B7259E8.70904@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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).

> 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?

> >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.

> 
> >-------
> >
> >Re-enter the kernel to complete in progress PIO. Otherwise the
> >operation can be lost during migration.
> >
> >Signed-off-by: Marcelo Tosatti<mtosatti@redhat.com>
> >
> >Index: qemu-kvm/qemu-kvm.c
> >===================================================================
> >--- qemu-kvm.orig/qemu-kvm.c
> >+++ qemu-kvm/qemu-kvm.c
> >@@ -967,6 +967,7 @@ int kvm_run(CPUState *env)
> >                                  run->io.direction,
> >                                  run->io.size,
> >                                  run->io.count);
> >+            r = 0;
> >              break;
> >          case KVM_EXIT_DEBUG:
> >              r = handle_debug(env);
> 
> 
> -- 
> Do not meddle in the internals of kernels, for they are subtle and quick to panic.