From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NkFRt-0003e6-Hw
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 06:30:37 -0500
Received: from [199.232.76.173] (port=34351 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NkFRs-0003dp-Sx
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 06:30:36 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <paul@codesourcery.com>) id 1NkFRs-0002Qq-Dy
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 06:30:36 -0500
Received: from mx20.gnu.org ([199.232.41.8]:63681)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1NkFRq-0002Q4-UQ
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 06:30:35 -0500
Received: from mail.codesourcery.com ([38.113.113.100])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1NkFRl-0007ge-9G
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 06:30:29 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Re: [PATCH-RFC 13/13] virtio-net: connect to vhost
	net backend
Date: Wed, 24 Feb 2010 11:30:18 +0000
References: <cover.1263230079.git.mst@redhat.com>
	<201002240314.25631.paul@codesourcery.com>
	<20100224052925.GA27806@redhat.com>
In-Reply-To: <20100224052925.GA27806@redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201002241130.19317.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>

> On Wed, Feb 24, 2010 at 03:14:25AM +0000, Paul Brook wrote:
> > > vnet_hdr is IMHO a really bad example to copy from.
> > >
> > > vnet_hdr leaks into the migration state via n->has_vnet_hdr.  What this
> > > means is that if you want to migrate from -net tap -net
> > > nic,model=virtio to -net user -net nic,model=virtio, it will fail.
> > >
> > > This is a hard problem to solve in qemu though because it would require
> > > that we implement software GSO which so far, no one has stepped up to
> > > do.
> >
> > Or make virtio-net pass this on to the guest, and have that deal with the
> > problem.
> 
> This is exacly what we do, via feature bits.

AFAIK we only have static feature bits. There aren't useful for anything that 
the user may change on the fly (or via migration).

If you don't have a fallback implementation then the guest must be able to 
cope with this feature disappearing without warning. If we do have a software 
fallback then the feature bit is just for backwards compatibility, and should 
be enabled unconditionally (on current machine types).

Paul