Rusty Russell <rusty@xxxxxxxxxxxxxxx> writes: > "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: >> 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. > > True, but it's the guest which allocates the ring. If QEMU sets up a > guest with a offset-discontiguous mapping, vhost would be unreliable > today. My mistake: the ring addresses handed through the ioctl already translated, so you can't specify such a thing. I struck this when I tried to clean it up: this is an asymmetry between the toplevel descriptor table and any indirect ones. Cheers, Rusty. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
