Date: Mon, 27 May 2013 22:51:44 -0500 (CDT) From: Bryan Venteicher <bryanv@daemoninthecloset.org> To: Julian Stecklina <jsteckli@os.inf.tu-dresden.de> Cc: freebsd-virtualization@freebsd.org Subject: Re: virtio-net vs qemu 1.5.0 Message-ID: <970038826.7286.1369713104543.JavaMail.root@daemoninthecloset.org> In-Reply-To: <knobss$316$1@ger.gmane.org> References: <knl0cv$il4$1@ger.gmane.org> <knobss$316$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, ----- Original Message ----- > Hello, > > I filed a bug: > http://www.freebsd.org/cgi/query-pr.cgi?pr=178955 > I committed a fix to this in the multiqueue driver [1] during BSDCan, haven't merged it back into HEAD yet. I'll do that in a couple of days. Unless you have multiple MAC unicast and/or multicast addresses configured on an interface, the error is harmless (for QEMU, which AFAIK, is the only implementation that supports this feature). [1] http://svnweb.freebsd.org/base?view=revision&revision=250802 > Julian > > On 05/23/2013 02:00 PM, Julian Stecklina wrote: > > Hello, > > > > I just compiled qemu 1.5.0 and noticed that virtio network (on CURRENT as > > of today) seems to have problems updating the MAC filter table: > > > > vtnet0: error setting host MAC filter table > > > > As far as I understand, if_vtnet.c does the following in > > vtnet_rx_filter_mac. It appends two full struct vtnet_mac_tables (one for > > unicast and one for multicast) to the request. Each consists of the number > > of actual entries in the table and space for 128 (mostly unused) entries > > in total. > > > > The qemu code parses this differently. It first reads the number of > > elements in the first table and then skips over so many MAC addresses and > > then expects the header to the second table (which in our case points to > > zero'd memory). Then it skips those 0 MAC entries as well and expects that > > it has consumed the whole request and returns an error, because there is > > still data left. The relevant code is in qemu/hw/net/virtio-net.c in > > virtio_net_handle_rx_mode. > > > > Assuming the qemu code is correct (of which I am not sure) the correct > > solution would be to enqueue only so many MACs in the original requests as > > are actually used. The following (a bit dirty) patch fixes this for me: > > > > > > diff --git a/sys/dev/virtio/network/if_vtnet.c > > b/sys/dev/virtio/network/if_vtnet.c > > index ffc349a..6f00dfb 100644 > > --- a/sys/dev/virtio/network/if_vtnet.c > > +++ b/sys/dev/virtio/network/if_vtnet.c > > @@ -2470,9 +2470,9 @@ vtnet_rx_filter_mac(struct vtnet_softc *sc) > > sglist_init(&sg, 4, segs); > > error |= sglist_append(&sg, &hdr, sizeof(struct > > virtio_net_ctrl_hdr)); > > error |= sglist_append(&sg, &filter->vmf_unicast, > > - sizeof(struct vtnet_mac_table)); > > + sizeof(uint32_t) + > > ETHER_ADDR_LEN*filter->vmf_unicast.nentries); > > error |= sglist_append(&sg, &filter->vmf_multicast, > > - sizeof(struct vtnet_mac_table)); > > + sizeof(uint32_t) + > > ETHER_ADDR_LEN*filter->vmf_multicast.nentries); > > error |= sglist_append(&sg, &ack, sizeof(uint8_t)); > > KASSERT(error == 0 && sg.sg_nseg == 4, > > ("error adding MAC filtering message to sglist")); > > > > Any virtio guru here to comment on this? > > > > Julian > > > > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?970038826.7286.1369713104543.JavaMail.root>