From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH][RFC] Prepare virtio for upstream QEMU merging Date: Thu, 16 Oct 2008 11:55:18 +0200 Message-ID: <48F70F86.7080205@redhat.com> References: <48F3934E.9040809@codemonkey.ws> <48F4C4FF.8020207@redhat.com> <48F4C6FF.4010801@codemonkey.ws> <48F4D74A.5090602@redhat.com> <48F4E024.70700@codemonkey.ws> <48F5F6DD.4020402@redhat.com> <48F5F9FE.3010200@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:47281 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753168AbYJPJzX (ORCPT ); Thu, 16 Oct 2008 05:55:23 -0400 In-Reply-To: <48F5F9FE.3010200@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: >>> >>> But that will require refactoring a lot of these optimizations. In >>> order to do that right, they need to be presented on qemu-devel. >>> It's a whole lot easier to do that incrementally so that people can >>> digest it all instead of blasting a big series. >> >> Can you elaborate? Which interfaces will need rework, and why? > > Last time I tried, virtio-net doesn't work with slirp. I believe it's > either because of the GSO changes (unlikely) or because of the > can_receive changes (more likely). The can_receive changes probably > need some refactoring to be more slirp friendly. The GSO changes are > a bit vlan unfriendly. > > Right now, you could construct something like -net tap -net > nic,model=virtio -net model=e1000. e1000 doesn't support GSO and bad > things will happen from this. It's very centric to the single-nic, > single-host driver model. Also, exposing something like > tap_has_vnet_hdr() to the actual network cards violates the layering. > The network cards shouldn't have any knowledge of what types of host > drivers there are, just what features a particular VLAN supports. > > It's also unclear how you handle things like NIC hot-plug. What if > you add a nic that doesn't support GSO to a VLAN that is using GSO? > What about migration? What if you migrate from a host that has GSO > support to a host that doesn't support GSO? This later problem is > hard and would require either a feature renegotiation mechanism in > virtio or software implementation of GSO within QEMU. Okay, we can go along with mangling the current virtio implementation like you proposed. -- error compiling committee.c: too many arguments to function