Anthony Liguori wrote: > > You can have the file descriptor be opened O_RDONLY so trust isn't an > issue. > Reading is just as bad as writing. >> This implies trusting the other userspace, which is not a good >> thing. Let the kernel copy, we already trust it, and it has more >> resources to do the copy. >> > > You're going to end up with the same trust issues no matter what > unless you let the kernel look directly at the virtio ring queue. > That's the only way to arbitrate what memory gets copied. That's what we need, then. > There may be a generic API here for fast interprocess IO, I don't > know. splice() is a little awkward though for this because you really > don't want to sit in a splice() loop. What you want is for both sides > to be kick'ing the kernel and the kernel to raise an event via > eventfd() or something. > > Absent whatever this kernel API is (which is really just helpful with > a DMA engine), I think the current userspace approach is pretty > reasonable. Not just for interguest IO but also for driver domains > which I think is a logical extension. I disagree. A driver domain is shared between multiple guests, and if one of the guests manages to break into qemu then it can see other guest's data. [Driver domains are a horrible idea IMO, but that's another story] -- error compiling committee.c: too many arguments to function _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
