From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSXXQ-0002Yw-0e for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:11:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSXXL-0002XX-33 for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:11:07 -0500 Received: from [199.232.76.173] (port=44143 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSXXK-0002XU-TW for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:11:02 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]:39243) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSXXI-0001eD-Hb for qemu-devel@nongnu.org; Wed, 06 Jan 2010 10:11:00 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o06EvWx2004410 for ; Wed, 6 Jan 2010 07:57:32 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o06FAblq225746 for ; Wed, 6 Jan 2010 08:10:45 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o06FAVSE024821 for ; Wed, 6 Jan 2010 08:10:31 -0700 Message-ID: <4B44A7E6.5030300@linux.vnet.ibm.com> Date: Wed, 06 Jan 2010 09:10:30 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Planning for 0.13 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> <20100106132043.GC2248@redhat.com> <4B449162.9040107@linux.vnet.ibm.com> <20100106135527.GE2248@redhat.com> In-Reply-To: <20100106135527.GE2248@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org On 01/06/2010 07:55 AM, Michael S. Tsirkin wrote: > On Wed, Jan 06, 2010 at 07:34:26AM -0600, Anthony Liguori wrote: > >> On 01/06/2010 07:20 AM, Michael S. Tsirkin wrote: >> >>>> 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. >>> >> It's the same mechanism, no? >> >> I want to move to a single net backend that would be something like -net >> fd. Here are some possible invocations: >> >> -net fd,fd=3,type=tun,vnet=off >> -net fd,helper="/usr/libexec/qemu-net-vepa --arg-if=eth0" >> -net fd,fd=3,type=socket,vnet=off >> > We currently don't let users control whether vnet header > is activated in tap and IMO we are better off this way, > let qemu find out support itself. > -net tap,vnet_hdr=off >> -net fd,fd=3,type=vhost >> >> It's really a simple thing to do and it means that we can always >> implement any backend outside of qemu. >> > Look at existing backends, each of them has some quirks in qemu. It's > not realistic to expect that future backends won't need any more. > Quirks in the send/receive paths? Can you be specific because I don't really think there are. >> As part of this, I would like: >> >> -net vepa,if=eth0 >> >> To automatically translate to: >> >> -net fd,helper="/usr/libexec/qemu-net-vepa --arg-if=eth0" >> >> I'm also open to the idea of using shared libraries if people really >> think it's a good idea. >> > What does all of this buy us? The helpers will still need to be shipped > with qemu. > Why? They can be separate packages that are maintained on their own and at their own pace. >> There really isn't much a protocol here. Helpers get handed a domain >> socket, then connect and send an fd via SCM_RIGHTS. They pass a string >> as part of that message that just happens to be equivalent to the arg >> string that would normally be passed to -net fd. >> > How do helpers know which arguments are legal? There is a set number of arguments that we support in qemu.. I think this is the sort of thing that is easier to discuss with code in hand. > Also, e.g. with > vhost-net you can open it in a helper script but you must do the rest of > the set up in qemu. > AFAICT, we have a hand full of types of fds. We have ones that require read/write, ones that require send/recv, and ones that require vhost interaction. Really, the first two are the same but the distinction is necessary for Windows. >>>> 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. >>> >>> >> It's not about security, it's about not making qemu the gateway to >> implementing arbitrarily complex network mechanisms. There's no reason >> qemu should have to know anything about vepa, for instance. >> >> Regards, >> >> Anthony Liguori >> > We'll still need to write all the scripts and bundle them > with qemu. So ... I fail to see > Again, I don't see why it needs to be bundled with qemu. Regards, Anthony Liguori