Re: [RFC PATCH 0/4] Inter-guest virtio I/O example with lguest

Avi Kivity
2008-03-20T15:36:34Z

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.