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. Thing is, we are heading towards virtio. Unfortunately, virtio_net currently does not offer a method to register multicast addresses. Rusty, do you think its worthwile to notify the host about registered multicast addresses? Christian _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
