From patchwork Wed Dec 5 11:08:07 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Michael S. Tsirkin" X-Patchwork-Id: 203850 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id DF5F72C00C4 for ; Wed, 5 Dec 2012 22:05:21 +1100 (EST) Received: from localhost ([::1]:51137 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgCn1-0001En-Vt for incoming@patchwork.ozlabs.org; Wed, 05 Dec 2012 06:05:19 -0500 Received: from eggs.gnu.org ([208.118.235.92]:44329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgCmn-0001Ag-O4 for qemu-devel@nongnu.org; Wed, 05 Dec 2012 06:05:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TgCmg-00037T-Gf for qemu-devel@nongnu.org; Wed, 05 Dec 2012 06:05:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58115) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgCmg-00037I-9D for qemu-devel@nongnu.org; Wed, 05 Dec 2012 06:04:58 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qB5B4usJ022185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Dec 2012 06:04:57 -0500 Received: from redhat.com (vpn1-5-86.ams2.redhat.com [10.36.5.86]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id qB5B4sGh021478; Wed, 5 Dec 2012 06:04:55 -0500 Date: Wed, 5 Dec 2012 13:08:07 +0200 From: "Michael S. Tsirkin" To: Rusty Russell Message-ID: <20121205110807.GA10045@redhat.com> References: <87624iikcw.fsf@rustcorp.com.au> <87zk1uca8z.fsf@elfo.mitica> <87r4n5h0fx.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87r4n5h0fx.fsf@rustcorp.com.au> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: QEMU-devel , quintela@redhat.com Subject: [Qemu-devel] [PATCH] virtio: verify that all outstanding buffers are flushed (was Re: vmstate conversion for virtio?) X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Add sanity check to address the following concern: On Wed, Dec 05, 2012 at 09:47:22AM +1030, Rusty Russell wrote: > All we need is the index of the request; the rest can be re-read from > the ring. I'd like to point out that this is not generally true 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 diff --git a/hw/virtio.c b/hw/virtio.c index f40a8c5..b80a5a9 100644 --- a/hw/virtio.c +++ b/hw/virtio.c @@ -788,6 +788,8 @@ void virtio_save(VirtIODevice *vdev, QEMUFile *f) if (vdev->vq[i].vring.num == 0) break; + assert(!vq->inuse); + qemu_put_be32(f, vdev->vq[i].vring.num); qemu_put_be64(f, vdev->vq[i].pa); qemu_put_be16s(f, &vdev->vq[i].last_avail_idx);