Re: [PATCH 1/6] virtio_host: host-side implementation of virtio rings.

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Jan 21, 2013 at 10:22:03PM +1030, Rusty Russell wrote:
> Rusty Russell <rusty@rustcorp.com.au> writes:
> > "Michael S. Tsirkin" <mst@redhat.com> writes:
> >>> +		iov->iov[iov->i].iov_base = (__force __user void *)addr;
> >>> +		iov->iov[iov->i].iov_len = desc.len;
> >>
> >> The following comment from the previous version still applies:
> >> 	> This looks like it won't do the right thing if desc.len spans multiple
> >> 	> ranges. I don't know if this happens in practice but this is something
> >> 	> vhost supports ATM.
> >> in otgher words, we might need to split a single desc to multiple
> >> iov entries.
> >
> > Ah, separate offsets for consecutive ranges, right.  I'd prefer to say
> > "don't do that", but qemu is rarely sane.  I'll fix it.
> 
> Actually, you make the same assumption for vhost, with your use of
> getuser and putuser for accessing the ring.

There's no requirement that ring is mapped directly into guest
memory. If a ring is not contigious qemu can allocate
it's own virtuall contigious rings and copy data back and forth.

> The complexity and cost of handling this is significant,

Why is it? Just add a while loop, increment desc.addr
and decrement desc.len.

> and the error
> if it ever did happen is distinctive.  Does qemu ever create such
> things?
> 
> Thanks,
> Rusty.

I think qemu does create ranges that are consequitive in guest pa
space but not in qemu va ranges. I'm sick today, will try to dig out
some examples later.

-- 
MST