Re: [PATCH][RFC] Prepare virtio for upstream QEMU merging

[Avi Kivity <avi@redhat.com>]

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