From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSV7s-0000xf-Bd for qemu-devel@nongnu.org; Wed, 06 Jan 2010 07:36:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSV7n-0000se-HK for qemu-devel@nongnu.org; Wed, 06 Jan 2010 07:36:36 -0500 Received: from [199.232.76.173] (port=49250 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSV7n-0000sX-CE for qemu-devel@nongnu.org; Wed, 06 Jan 2010 07:36:31 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:40213) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSV7n-0001rT-0m for qemu-devel@nongnu.org; Wed, 06 Jan 2010 07:36:31 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e9.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o06CSsBN018271 for ; Wed, 6 Jan 2010 07:28:54 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o06CaSPu126550 for ; Wed, 6 Jan 2010 07:36:28 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o06CaRve013413 for ; Wed, 6 Jan 2010 10:36:28 -0200 Message-ID: <4B4483CA.2030101@linux.vnet.ibm.com> Date: Wed, 06 Jan 2010 06:36:26 -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> In-Reply-To: <20100106104903.GA2248@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 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. 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. Regards, Anthony Liguori