Re: [PATCH] Use QEMU functions to access guest memory for virtio

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

Avi Kivity wrote: 
>
> I don't think a full blown dma api is that horrible.  You need a 
> function that translates a phys vectors to iovecs.  A slight 
> complication is that the vectors can be of different sizes, but it's 
> still not that bad.

Yeah, I've already started on that.  One of the problems is the virtio 
backends currently assume that the first element of the SG list is the 
header instead of the first sizeof(header) bytes.  I'm fixing this now 
but the DMA api works pretty well.  Surprisingly, even doing copy at the 
DMA layer with cpu_physical_memory_rw only causes a 10% hit on 
virtio_net performance.  I still need to implement something smarter 
than phys_ram_base + PA so we can avoid that hit and still work with > 
4GB of memory.

> If we add memory hotplug later, we need to lock it out when dma is 
> happening, so it's best to add a dummy release function.

Yeah, the release function is there to support the copy mode.  The copy 
mode is what I'm going to try to push into upstream QEMU.  The only 
tricky part is whether we'll get away with a DMA abstraction in virtio 
or whether we'll have to put it in the PCI layer.  If it's a simple 
map/unmap functions it's not a big deal but I don't know what else would 
be needed from a PCI DMA API.

>> +
>> +static uint64_t vring_desc_addr(VirtQueue *vq, unsigned int i)
>> +{
>> +    return ldq_phys(vq->vring.desc + i * 16 + 0);
>> +}
>>   
>
> #define s_ld_u64(phys, field, type) \
>       ldq_phys(phys + offsetof(field, type))
>
>
> And now we don't need individual accessors, or to encode the offsets 
> as magic numbers.

It's a nice thought but it doesn't work out in practice because most of 
these accessor functions are accessing array elements.  However, I 
thought about using offsetof() to eliminate the magic constants and I 
don't think that's a bad idea.  In the very least, it makes the code 
more readable.  It'll be part of the next series.

> An additional bonus is that the code is endian safe now.
>
> If the qemu translation lookup is slow, there are ways to speed it up, 
> so I'm not worried about speed.

It doesn't look like it's going to be a performance problem but yeah, I 
was thinking the same thing.

Regards,

Anthony Liguori


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace