From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TimiG-0004JP-Vz for qemu-devel@nongnu.org; Wed, 12 Dec 2012 08:51:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Timi7-0004VX-FT for qemu-devel@nongnu.org; Wed, 12 Dec 2012 08:51:04 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:42512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Timi7-0004VT-5j for qemu-devel@nongnu.org; Wed, 12 Dec 2012 08:50:55 -0500 Received: by mail-bk0-f45.google.com with SMTP id jk13so361099bkc.4 for ; Wed, 12 Dec 2012 05:50:52 -0800 (PST) Date: Wed, 12 Dec 2012 14:50:50 +0100 From: Stefan Hajnoczi Message-ID: <20121212135050.GC16270@stefanha-thinkpad.redhat.com> References: <20121212105101.GA6461@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121212105101.GA6461@redhat.com> Subject: Re: [Qemu-devel] [PATCHv2] virtio: verify that all outstanding buffers are flushed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Anthony Liguori , Rusty Russell , qemu-devel@nongnu.org, Avi Kivity , Stefan Hajnoczi , Paolo Bonzini On Wed, Dec 12, 2012 at 12:51:01PM +0200, Michael S. Tsirkin wrote: > Add sanity check to address the following concern: > > During migration, all we pass the index of the request; > the rest can be re-read from the ring. > > This is not generally enough if any available requests are outstanding. > Imagine a ring of size 4. Below A means available U means used. > > A 1 > A 2 > U 2 > A 2 > U 2 > A 2 > U 2 > A 2 > U 2 > > At this point available ring has wrapped around, the only > way to know head 1 is outstanding is because backend > has stored this info somewhere. > > The reason we manage to migrate without tracking this in migration > state is because we flush outstanding requests before > migration. > This flush is device-specific though, let's add > a safeguard in virtio core to ensure it's done properly. > > Signed-off-by: Michael S. Tsirkin > --- > > Changes from v1: > v1 was against the wrong tree, it didn't build against qemu.git > > hw/virtio.c | 2 ++ > 1 file changed, 2 insertions(+) VirtIOBlock->rq can trigger the assertion. IIUC hw/virtio-blk.c may handle I/O errors by keeping the request pending and on a list (->rq). This allows the user to restart them after, for example, adding more space to the host file system containing the disk image file. We keep a list of failed requests and we migrate this list. So I think inuse != 0 when migrating with pending failed I/O requests. Stefan