Re: [Qemu-devel] Re: [PATCH 2/3] virtio network device

[Anthony Liguori <aliguori@us.ibm.com>]

Paul Brook wrote:
>>> Actually according to qemu's standard, one should use
>>> cpu_physical_memory_write/ cpu_physical_memory_read functions.
>>> This is true also for reading the ring values.
>>>       
>> Yes, and unfortunately, cpu_physical_memory_{read,write} are copy
>> interfaces.  We really don't want that for high speed I/O.
>>     
>
> I really don't like doing direct access to guest ram without implementing a 
> proper API for zero-copy/scatter-gather access. There was a list thread about 
> this not so long ago.
>   

I agree that we need a proper API for sg ram access.  I'm going to look 
into that real soon since it's necessary to optimize the network/disk 
transports.

virtio makes things a bit trickier though.  There's a shared ring queue 
between the host and guest.  The ring queue is lock-less and depends on 
the ability to atomically increment ring queue indices to be SMP safe.  
Using a copy-API wouldn't be a problem for QEMU since the host and guest 
are always running in lock-step.  A copy API is actually needed to deal 
with differing host/guest alignment and endianness.

Once you introduce KVM though, this is no longer true since KVM supports 
true SMP.  The solution may be to implement some sort of 
atomic_increment function and then have that use a if (kvm) guard to do 
a direct access verses a copy.

Regards,

Anthony Liguori

> Paul
>