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
_______________________________________________
Lguest mailing list
Lguest@ozlabs.org
https://ozlabs.org/mailman/listinfo/lguest
