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

Avi Kivity
2008-03-20T14:55:35Z

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.

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.

> If you had a pv dma registration api you could conceivably only allow
> the active dma entries to be mapped but my fear would be that the
> zap'ing on unregister would hurt performance.
>

Yes, mmu games are costly. They also only work on page granularity
which isn't always possible to guarantee.

>>> Conceivably, this could be done as a read-only mapping so that each
>>> guest userspace copies only the rx packets. That's about as secure
>>> as you're going to get with this approach I think.
>>>
>>
>> Maybe we can terminate the virtio queue in the host kernel as a pipe,
>> and splice pipes together.
>>
>> That gives us guest-guest and guest-process communications, and if
>> you use aio the kernel can use a dma engine for the copy.
>
> Ah, so you're looking to use a DMA engine for accelerated copy.
> Perhaps the answer is to expose the DMA engine via a userspace API?

That's one option, but it still involves sharing all of memory.
Splicing pipes might be better.

--
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.