From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NkIyT-0003Yb-5t
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 10:16:29 -0500
Received: from [199.232.76.173] (port=55540 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NkIyR-0003Xw-J5
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 10:16:27 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <anthony@codemonkey.ws>) id 1NkIyP-0006p1-7k
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 10:16:27 -0500
Received: from mail-yw0-f197.google.com ([209.85.211.197]:58050)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NkIyO-0006ov-U5
	for qemu-devel@nongnu.org; Wed, 24 Feb 2010 10:16:25 -0500
Received: by ywh35 with SMTP id 35so2651807ywh.4
	for <qemu-devel@nongnu.org>; Wed, 24 Feb 2010 07:16:24 -0800 (PST)
Message-ID: <4B8542C6.1060900@codemonkey.ws>
Date: Wed, 24 Feb 2010 09:16:22 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH-RFC 13/13] virtio-net: connect to vhost
	net backend
References: <cover.1263230079.git.mst@redhat.com>	<201002240314.25631.paul@codesourcery.com>	<20100224052925.GA27806@redhat.com>	<201002241130.19317.paul@codesourcery.com>
	<20100224114605.GA32125@redhat.com>
In-Reply-To: <20100224114605.GA32125@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

On 02/24/2010 05:46 AM, Michael S. Tsirkin wrote:
>
> Ah, you mean telling the guest to switch features on and off: natureally
> this would require guest driver changes.  This might be also non-trivial
> to implement. Consider a request that has been posted without checksum,
> suddenly we disable checksum support.  Guest will need a way to handle
> that.  Guest OSes might also not be prepared to handle device features
> going away.
>    

It's the same as cpuid flags.

Management tools should plan appropriately and not advertise virtio 
features that cannot be supported throughout the migration pool.  
Fortunately, someone had enough foresight to allow management software 
to disable virtio features on a per-feature basis :-)

Regards,

Anthony Liguori