netdev - Re: Multicast and receive filtering in TUN/TAP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Jul 2008 09:57:56 -0700
From:	Max Krasnyansky <maxk@...lcomm.com>
To:	Christian Borntraeger <borntraeger@...ibm.com>
CC:	virtualization@...ts.linux-foundation.org,
	Brian Braunstein <linuxkernel@...style.com>,
	Shaun Jackman <sjackman@...il.com>, netdev@...r.kernel.org,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: Multicast and receive filtering in TUN/TAP

Christian Borntraeger wrote:
> Am Donnerstag, 10. Juli 2008 schrieb Max Krasnyansky:
> [...]
>> The second question is do you guys think that QEMU/KVM/LGUEST/etc would 
>> benefit if receive filtering was done by the host OS. Here is a specific 
>> example of what I'm talking about.
>> We can do what qemu/hw/e1000.c:receive_filter() does in the _host_ 
>> context (that function currently runs in the guest context). By looking 
>> at libvirt, typical QEMU based setup is that you have a single bridge 
>> and all the TAPs from different VMs are hooked up to that bridge. What 
>> that means is that if one VM is getting MC traffic or when the bridge 
>> sees MACADDR that is not in its tables the packets get delivered to all 
>> the VMs. ie We have to wake all of the up only to so that they could 
>> drop that packet. Instead, we could setup filters in the host's side of 
>> the TAP device.
>> Does that sound like something useful for QEMU/KVM ?
>> If yes we can talk about the API. If not then I'll just nuke it.
> 
> Max,
> 
> I know that on s390 the shared OSA network card have multicast filter 
> capabilities. So I guess it is worthwile for a virtualization environments 
> with lots of guests. I also think, that this kind of filtering should be 
> straightforward to implement with the qemu e1000 code. Qemu already knows the 
> multicast addresses.
Sure. It's straightforward to do inside QEMU, and it's already doing it.
The question is should we do it in the host context instead and avoid some
wakeups.

> Thing is, we are heading towards virtio. 
Even for Windows ?

> Unfortunately, virtio_net currently  does not offer a method to register multicast addresses.
I haven't looked at the virtio stuff much, I was assuming that the host side
of it is still the TUN driver. Is it not ?

Max
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html