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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
