From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MySdv-00072t-MO for qemu-devel@nongnu.org; Thu, 15 Oct 2009 11:53:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MySdr-00071U-8c for qemu-devel@nongnu.org; Thu, 15 Oct 2009 11:53:31 -0400 Received: from [199.232.76.173] (port=51212 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MySdr-00071R-2v for qemu-devel@nongnu.org; Thu, 15 Oct 2009 11:53:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33995) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MySdp-0003vg-5U for qemu-devel@nongnu.org; Thu, 15 Oct 2009 11:53:25 -0400 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n9FFrNIR029707 for ; Thu, 15 Oct 2009 11:53:23 -0400 Date: Thu, 15 Oct 2009 17:04:54 +0200 From: "Michael S. Tsirkin" Message-ID: <20091015150454.GA8620@redhat.com> References: <4ACDF550.1020502@codemonkey.ws> <20091014132154.GA29037@redhat.com> <4AD5DD6B.2030703@codemonkey.ws> <20091014142453.GA29798@redhat.com> <20091014151917.GB17062@shareable.org> <20091014155018.GB30179@redhat.com> <1255554600.20366.9.camel@w-sridhar.beaverton.ibm.com> <4AD65684.3010403@codemonkey.ws> <20091015075612.GB32003@redhat.com> <4AD72453.1050209@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD72453.1050209@codemonkey.ws> Subject: [Qemu-devel] Re: Raw vs. tap List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm-devel , qemu-devel@nongnu.org, Paul Brook , Jens Osterkamp , Sridhar Samudrala On Thu, Oct 15, 2009 at 08:32:03AM -0500, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> On Wed, Oct 14, 2009 at 05:53:56PM -0500, Anthony Liguori wrote: >> >>> I would be much more inclined to consider taking raw and improving >>> the performance long term if guest<->host networking worked. This >>> appears to be a fundamental limitation though and I think it's >>> something that will forever plague users if we include this feature. >>> >> >> In fact, I think it's fixable with a raw socket bound to a macvlan. >> Would that be enough? >> > > What setup does that entail on the part of a user? Wouldn't we be back > to square one wrt users having to run archaic networking commands in > order to set things up? Unlike bridge, qemu could set up macvlan without disrupting host networking. The only issue would be cleanup if qemu is killed. > Regards, > > Anthony Liguori >