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

[Anthony Liguori <anthony@codemonkey.ws>]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>>>> Why not merge these bits prior to merging virtio?  They aren't kvm
>>>>> specific and would be good in mainline qemu.
>>>>>         
>>>> I'd rather have a consumer of an interface before merging the actual
>>>> infrastructure.
>>>>
>>>>     
>>>
>>> So merge them all into qemu at the same time (as separate patches, if
>>> you like).
>>>   
>>
>> 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.

>>
>>> The amount of code duplication is frightening.
>>>   
>>
>> I've already got that worked out.  I need to prepare and commit a 
>> patch to fix stw/lduw in upstream QEMU and then we can switch to 
>> always using those functions in KVM.  I've done some performance 
>> testing and that seems to be enough.  With that, there is no longer 
>> any scary code duplication.
>
> Yes, your patch on qemu-devel looks good.  Even if we do have a 
> performance problem (which may well turn out after we optimize things 
> some more), it's easy to have a cached pointer along with the phys 
> address.

And I don't think that patch matters anymore :-/  I was doing 
measurements with iperf doing TX in the guest.  The numbers are very 
erratic and I mistakenly attributed a boost to that patch. 

Measuring based on RX seems to be more reliable since we're pegging the 
CPU.  We idle too much in TX due to the tx mitigation timeouts.

Regards,

Anthony Liguori