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

[Anthony Liguori <anthony@codemonkey.ws>]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/