Avi Kivity wrote: > Anthony Liguori wrote: >> Avi Kivity wrote: >>> Anthony Liguori wrote: >>>> Avi Kivity wrote: >>>> >>>> Each guest's host userspace mmaps the other guest's address space. >>>> The userspace then does a copy on both the tx and rx paths. >>>> >>> >>> Well, that's better security-wise (I'd still prefer to avoid it, so >>> we can run each guest under a separate uid), but then we lose >>> performance wise. >> >> What performance win? I'm not sure the copies can be eliminated in >> the case of interguest IO. >> > > I guess not. But at least you can dma instead of busy-copying. > >> Fast interguest IO means mmap()'ing the other guest's address space >> read-only. You can have the file descriptor be opened O_RDONLY so trust isn't an issue. > 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. 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. Regards, Anthony Liguori _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
