From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50798)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1a3hu4-0001OE-O2
	for qemu-devel@nongnu.org; Tue, 01 Dec 2015 05:11:26 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1a3hu1-0008Fg-Fz
	for qemu-devel@nongnu.org; Tue, 01 Dec 2015 05:11:20 -0500
Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:40909)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <cornelia.huck@de.ibm.com>) id 1a3hu1-0008FX-5s
	for qemu-devel@nongnu.org; Tue, 01 Dec 2015 05:11:17 -0500
Received: from localhost
	by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <qemu-devel@nongnu.org> from <cornelia.huck@de.ibm.com>;
	Tue, 1 Dec 2015 10:11:15 -0000
Received: from b06cxnps4074.portsmouth.uk.ibm.com
	(d06relay11.portsmouth.uk.ibm.com [9.149.109.196])
	by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 21DEE17D8063
	for <qemu-devel@nongnu.org>; Tue,  1 Dec 2015 10:11:40 +0000 (GMT)
Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com
	[9.149.37.217])
	by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with
	ESMTP id tB1ABBpq47841396
	for <qemu-devel@nongnu.org>; Tue, 1 Dec 2015 10:11:12 GMT
Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1])
	by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with
	ESMTP id tB1ABBUj013268
	for <qemu-devel@nongnu.org>; Tue, 1 Dec 2015 03:11:11 -0700
Date: Tue, 1 Dec 2015 11:11:08 +0100
From: Cornelia Huck <cornelia.huck@de.ibm.com>
Message-ID: <20151201111108.6dd85381.cornelia.huck@de.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] [2.5 issue] virtio-1 in virtio-net and old vhost
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>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>, Jason Wang <jasowang@redhat.com>, qemu-devel@nongnu.org

Some of our test folks tried to run a recent-ish qemu (nearly 2.5)
combined with an old host kernel (and a virtio-1 capable guest).

In that setup, we had the transport (in that case, virtio-ccw)
advertise VERSION_1 as it is a revision 1 device. However, the old
vhost driver did not support virtio-1 and therefore cleared the
VERSION_1 bit. In the end, qemu did not offer VERSION_1 to the guest
for a revision 1 device, which the guest treats as a fatal error.

It looks to me as if virtio-pci has the same problem: The kernel will
detect a modern device as by the I/O layout and then barf at the
missing VERSION_1 feature bit.

We _could_ make this missing VERSION_1 bit non-fatal in the guest, but
that does not fix guests that are already out there.

The problem is that the transport cannot know whether the VERSION_1 bit
will be pulled from under it later during device setup: This is only
done in the ->get_features() callback when virtio-net will handle the
features supported by vhost.

I'm currently lacking a good idea on how to fix this, but I think that
is an issue that should be dealt with for 2.5...