From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MDm0q-0006XA-R1 for qemu-devel@nongnu.org; Mon, 08 Jun 2009 17:04:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MDm0l-0006Wa-U0 for qemu-devel@nongnu.org; Mon, 08 Jun 2009 17:04:12 -0400 Received: from [199.232.76.173] (port=41134 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MDm0l-0006WX-ON for qemu-devel@nongnu.org; Mon, 08 Jun 2009 17:04:07 -0400 Received: from mx20.gnu.org ([199.232.41.8]:63418) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MDm0l-0001mL-9k for qemu-devel@nongnu.org; Mon, 08 Jun 2009 17:04:07 -0400 Received: from mail-qy0-f191.google.com ([209.85.221.191]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MDm0k-0005Cb-JL for qemu-devel@nongnu.org; Mon, 08 Jun 2009 17:04:06 -0400 Received: by qyk29 with SMTP id 29so4301076qyk.4 for ; Mon, 08 Jun 2009 14:04:03 -0700 (PDT) Message-ID: <4A2D7CB6.5060101@codemonkey.ws> Date: Mon, 08 Jun 2009 16:03:50 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 6/7] virtio-net: Add new RX filter controls References: <20090605204647.3355.81929.stgit@kvm.aw> <20090605204718.3355.28647.stgit@kvm.aw> <20090606204845.GC26877@redhat.com> <7162ab20906081201y4c598899mdfd5d42c42e17038@mail.gmail.com> <4A2D63EC.9040003@codemonkey.ws> <20090608192911.GA32168@redhat.com> In-Reply-To: <20090608192911.GA32168@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: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, Alex Williamson , "Michael S. Tsirkin" Daniel P. Berrange wrote: > On Mon, Jun 08, 2009 at 02:18:04PM -0500, Anthony Liguori wrote: > >> Alex Williamson wrote: >> >>> e1000 also allows the driver to selectively enable/disable RX of >>> packets to the broadcast address. This is replicated with the >>> all/no-bcast options. Finally, there may be cases where we want to >>> receive only unicast or only multicast address for special purpose >>> network devices. This is provided by the nouni and nomulti options. >>> A proprietary guest know as DMX intends to make use of these extra >>> modes. Are there any other interesting, useful and lightweight packet >>> filters we could implement? Thanks, >>> >>> >> I've been thinking about whether doing VLAN filtering/tagging within >> QEMU would make sense. It could potentially simplify bridge setups >> tremendously. Today, if you want to isolate VMs on separate vlans, it >> involves creating multiple bridges which gets ugly quickly. >> > > The downside of that would be that you're trusting the integrity of > QEMU for VLAN filtering. If QEMU got compromised then it could get > outside the configured VLAN, which is not possible if the VLAN stuff > is done by the kernel (assuming the QEMU process does not have the > capabilities to add itself to other bridges). > I guess that you can do: tunctl -p -t tap0 ifconfig tap0 0.0.0.0 up vconfig add tap0 32 brctl addif br0 tap0 And then use tap0.32 as your device for QEMU. The awkward thing though is that I don't think you can use TUNSETIFF to set the tun device name to tap0.32. But basically, this is the level of functionality that I think is need. The current mechanism of: vconfig add eth0 32 brctl addif br0 eth0.32 tunctl -p -t tap0 ifconfig tap0 0.0.0.0 up brctl addif br0 tap0 Is a pain because then you need a bridge for every possible vlan. Things get even more complicated when you have to deal with live migration and nested vlan tags. Regards, Anthony Liguori