From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSVrX-0004rl-Df for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:23:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSVrS-0004pZ-Os for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:23:47 -0500 Received: from [199.232.76.173] (port=33841 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSVrS-0004pV-FY for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:23:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42438) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSVrS-0000n9-3a for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:23:42 -0500 Date: Wed, 6 Jan 2010 15:20:45 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: Planning for 0.13 Message-ID: <20100106132043.GC2248@redhat.com> References: <4B4333DF.8090303@linux.vnet.ibm.com> <20100105213350.GC30921@redhat.com> <4B43DA17.8080001@codemonkey.ws> <20100106104903.GA2248@redhat.com> <4B4483CA.2030101@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4483CA.2030101@linux.vnet.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On Wed, Jan 06, 2010 at 06:36:26AM -0600, Anthony Liguori wrote: > On 01/06/2010 04:49 AM, Michael S. Tsirkin wrote: >>> What's the remaining problem? >>> >> IIRC, proper memory/IO access filtering (get rid of map functions) and >> PCI Express. >> >> >>>> vepa networking >>>> >>>> >>> To me, this is covered with helpers. I really want to get qemu out of >>> the network setup business specifically because of things like vepa, >>> vmtag, and all of the other weird things that can be done. >>> >> I don't think you can now make vepa work this way. For existing >> kernels, they only way I see is using packet sockets, and that code >> already mostly works. One day, when macvtap is ready - who knows. But >> waiting for that would mean we won't have it in 0.13. >> > > We can use helpers for more than just tun/tap. My current thinking for > helpers is that they would give qemu an fd and then tell qemu how to > work with it. Basically, use read/write vs. send/recv, whether to use a > virtio-net header or not, etc. Frankly I think this is too ambitious for 0.13, and I would like to avoid typing features that users need today to this effort. Note that management still needs ability to hand fd to qemu, so we can not require use of helpers for everyone. If the helpers are part of qemu itself, we do not gain anything from them besides (limited) security. But if not, we also get a protocol qemu<->helpers to maintain. Ugh. What I think is reasonable for 0.13, is what you posted: just allow helper script as an alternative way to get device fd, and have qemu do all the querying and feature negotiation exactly the way it already does. No protocol to maintain, command line users get some extra security, management is not affected at all. The only risk is that a new suid binary is installed. > That would allow a helper to open a raw socket, configure macvlan, and > then hand the fd over to qemu and tell qemu how to use it. Note binding to macvlan in a script buys you zero extra security as compared to opening socket and binding in qemu. > Regards, > > Anthony Liguori -- MST