From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NkGae-0007BI-Gb for qemu-devel@nongnu.org; Wed, 24 Feb 2010 07:43:44 -0500 Received: from [199.232.76.173] (port=55006 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NkGae-0007B9-49 for qemu-devel@nongnu.org; Wed, 24 Feb 2010 07:43:44 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NkGaa-0003No-JJ for qemu-devel@nongnu.org; Wed, 24 Feb 2010 07:43:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51500) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NkGaa-0003Nf-1F for qemu-devel@nongnu.org; Wed, 24 Feb 2010 07:43:40 -0500 Date: Wed, 24 Feb 2010 14:40:16 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH-RFC 13/13] virtio-net: connect to vhost net backend Message-ID: <20100224124016.GA1195@redhat.com> References: <201002241130.19317.paul@codesourcery.com> <20100224114605.GA32125@redhat.com> <201002241226.53893.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002241226.53893.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On Wed, Feb 24, 2010 at 12:26:53PM +0000, Paul Brook wrote: > > > 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. Yes, SW fallback might be nice to have. What's important is likely to depend on specific user. > Starting qemu on machine A and migrating to machine B should give the same > guest environment as starting on machine B. > > Paul So currently, the way we try to ensure this is by checking feature bits against the list supported by backend, and failing migration if there's a discrepancy. -- MST