On Mon, Jan 21, 2013 at 10:22:03PM +1030, Rusty Russell wrote: > Rusty Russell <rusty@xxxxxxxxxxxxxxx> writes: > > "Michael S. Tsirkin" <mst@xxxxxxxxxx> 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
