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
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
