From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC PATCH 0/4] Inter-guest virtio I/O example with lguest Date: Thu, 20 Mar 2008 17:36:34 +0200 Message-ID: <47E28482.9010501@qumranet.com> References: <200803201659.14344.rusty@rustcorp.com.au> <47E20A35.2000600@qumranet.com> <47E26CC1.8080900@codemonkey.ws> <47E27461.4090404@qumranet.com> <47E2771A.4060405@codemonkey.ws> <47E27AE7.7090503@qumranet.com> <47E27D1E.2090203@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , lguest , virtualization@lists.linux-foundation.org To: Anthony Liguori Return-path: In-Reply-To: <47E27D1E.2090203@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org 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. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/