From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58026)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1ZNZsc-0000BS-UZ
	for qemu-devel@nongnu.org; Fri, 07 Aug 2015 01:07:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1ZNZsZ-0003tR-Oj
	for qemu-devel@nongnu.org; Fri, 07 Aug 2015 01:07:42 -0400
Received: from mx1.redhat.com ([209.132.183.28]:40871)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1ZNZsZ-0003tM-JA
	for qemu-devel@nongnu.org; Fri, 07 Aug 2015 01:07:39 -0400
Received: from int-mx13.intmail.prod.int.phx2.redhat.com
	(int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])
	by mx1.redhat.com (Postfix) with ESMTPS id 3415636B172
	for <qemu-devel@nongnu.org>; Fri,  7 Aug 2015 05:07:39 +0000 (UTC)
Message-ID: <55C43D17.6010902@redhat.com>
Date: Fri, 07 Aug 2015 13:07:35 +0800
From: Jason Wang <jasowang@redhat.com>
MIME-Version: 1.0
References: <20150807012346-mutt-send-email-mst@redhat.com>
In-Reply-To: <20150807012346-mutt-send-email-mst@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] virtio 1 issues
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org



On 08/07/2015 06:31 AM, Michael S. Tsirkin wrote:
> Going over the code, I found a couple of issues.
> Recording them here since I won't be able to work
> on them until after the forum.
>
>
> 1. I realized we don't save/restore
> serialize the following fields in virtio pci:
>
>     uint32_t dfselect;
>     uint32_t gfselect;
>     uint32_t guest_features[2];
>     struct {
>         uint16_t num;
>         bool enabled;
>         uint32_t desc[2];
>         uint32_t avail[2];
>         uint32_t used[2];

desc, avail, used could be inferred from vring.desc, vring.avail and
vring.used
>     } vqs[VIRTIO_QUEUE_MAX];
>
> This isn't an issue unless VM is migrated during driver initialization.
>
> 2. ring resizing is broken - it actually has a comment:
>         /* TODO: need a way to put num back on reset. */
> guest that runs out of memory might down-size the ring.
> Afterwards, ring size won't come back up after reset - not nice.
>

Then we need a new field to keep track the original queue size and
migrate this.

>
> Given that the modern layout is disabled by default,
> I don't think these are release blockers.
>

Yes and looks like we need a new subsection and transport specific
callbacks to fix above?