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

[Avi Kivity <avi@qumranet.com>]

Anthony Liguori wrote:
> virtio is currently pretty sloppy about accessing guest memory directly.  This
> is problematic both because phys_ram_base + PA is not only valid but also
> because it requires the host and guest both be of the same endianness.
>
> This patch converts virtio to use the QEMU st/ld functions to manipulate the
> ring queues.  I've tested both virtio-blk and virtio-net.  I've also confirm
> that performance doesn't regress with virtio-net.
>
> We still use phys_ram_base to create the struct iovec to handle IO operations.
> I'm still trying to think of a way to eliminate that that doesn't involve an
> unnecessary copy or a full blown DMA API.
>   

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.

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.

> This patch should make it easier to use virtio with QEMU (in the absence of
> KVM).
>   

> +
> +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.

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.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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