From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NkIaC-0004fB-Gg for qemu-devel@nongnu.org; Wed, 24 Feb 2010 09:51:24 -0500 Received: from [199.232.76.173] (port=57848 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NkIaB-0004em-Ue for qemu-devel@nongnu.org; Wed, 24 Feb 2010 09:51:24 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NkIaA-0001DY-EL for qemu-devel@nongnu.org; Wed, 24 Feb 2010 09:51:23 -0500 Received: from mail-gx0-f209.google.com ([209.85.217.209]:41337) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NkIa9-0001DK-NM for qemu-devel@nongnu.org; Wed, 24 Feb 2010 09:51:22 -0500 Received: by gxk1 with SMTP id 1so1936901gxk.16 for ; Wed, 24 Feb 2010 06:51:21 -0800 (PST) Message-ID: <4B853CDC.7040806@codemonkey.ws> Date: Wed, 24 Feb 2010 08:51:08 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH-RFC 13/13] virtio-net: connect to vhost net backend References: <20100125202711.GA16928@redhat.com> <4B5E0660.6010400@codemonkey.ws> <201002240314.25631.paul@codesourcery.com> In-Reply-To: <201002240314.25631.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" On 02/23/2010 09:14 PM, 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. If you implement software GSO, then devices can assume it's always > present and don't need to probe. > That would make migration guest cooperative. This implies that the guests become an important part of the test matrix with respect to migration. The result is a combinatorial expansion of the test matrix. There's a lot of value in having transparent migration. Maybe it makes sense to have some sort of guest notification for the purposes of optimization, but we should be very careful about that because the practical cost is huge. Regards, Anthony Liguori > Paul >