On Mon, Jan 21, 2013 at 02:24:31PM +0200, Michael S. Tsirkin wrote: > 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. It seems it could happen if e.g. one region is ROM and another one is RAM. This means it won't be used for the ring (which is R/W) but could be for the data. > -- > MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
