From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NkGKX-0002yS-Nb
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 07:27:05 -0500
Received: from [199.232.76.173] (port=53663 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NkGKX-0002yB-DB
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 07:27:05 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <paul@codesourcery.com>) id 1NkGKW-00015o-P6
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 07:27:05 -0500
Received: from mx20.gnu.org ([199.232.41.8]:64432)
	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 1NkGKW-00015k-I7
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 07:27:04 -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 1NkGKV-0000jV-L6
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 07:27:04 -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 12:26:53 +0000
References: <cover.1263230079.git.mst@redhat.com>
	<201002241130.19317.paul@codesourcery.com>
	<20100224114605.GA32125@redhat.com>
In-Reply-To: <20100224114605.GA32125@redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201002241226.53893.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: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org

> > 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).
>
> Software fallback might turn out to be slower than disabling the feature
> in the guest. For example, and extra pass over packet might cause extra CPU
> cache thrashing. In that case, it's not obvious whether enabling it
> unconditionally will turn out to be a good idea. But we'll have to have
> that code to be able to tell.

IMO once you accept that these things can change, consistency is more 
important than trying to guess what the "best" option may be.
Starting qemu on machine A and migrating to machine B should give the same 
guest environment as starting on machine B.

Paul