From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH qemu-kvm] Add raw(af_packet) network backend to qemu Date: Thu, 28 Jan 2010 15:56:44 +0200 Message-ID: <20100128135644.GE3776@redhat.com> References: <4B5F54E8.3080507@codemonkey.ws> <20100127180338.GB13730@redhat.com> <4B6099E0.40101@codemonkey.ws> <201001280912.04809.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , Sridhar Samudrala , avi@redhat.com, markmc@redhat.com, ogerlitz@voltaire.com, kvm@vger.kernel.org, qemu-devel@vger.kernel.org To: Arnd Bergmann Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55573 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932208Ab0A1OAL (ORCPT ); Thu, 28 Jan 2010 09:00:11 -0500 Content-Disposition: inline In-Reply-To: <201001280912.04809.arnd@arndb.de> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jan 28, 2010 at 09:12:04AM +0100, Arnd Bergmann wrote: > On Wednesday 27 January 2010, Anthony Liguori wrote: > > >>> > > >> Introducing something that is known to be problematic from a security > > >> perspective without any clear idea of what the use-case for it is is a > > >> bad idea IMHO. > > >> > > > vepa on existing kernels is one use-case. > > > > > > > Considering VEPA enabled hardware doesn't exist today and the standards > > aren't even finished being defined, I don't think it's a really strong > > use case ;-) > > The hairpin turn (the part that is required on the bridge) was implemented > in the Linux bridge in 2.6.32, so that is one existing implementation you > can use as a peer. > > The VEPA mode in macvlan only made it into 2.6.33, so using the raw socket > on older kernels does not give you actual VEPA semantics. > > The part of the standard that is still under discussion is the management > side, which is almost entirely unrelated to this question though. With > Linux-2.6.33 on both sides using raw/macvlan and bridge respectively, > you can have a working VEPA setup. The only thing missing is that the > hypervisor will not be able to tell the bridge to automatically enable > hairpin mode (you need to do that on the bridge on a per-port basis). > > > Now, the most important use case I see for the raw socket interface > in qemu is to get vhost-net and the qemu user implementation to > support the same feature set. If you ask for a network setup involving > a raw socket and vhost-net and the kernel can support raw sockets > but for some reason fails to set up vhost-net, you should have a > fallback that has the exact same semantics at a possibly significant > performance loss. > > Arnd Makes sense. A simple reason you can't do vhost-net would be that you are using tcg. -- MST