[Qemu-devel] wrong argument to qemu_flush_queued_packets() in network frontends ?

[Luigi Rizzo]

While running qemu 1.3.0 with the following network-related flags:

        -net nic -net tap,ifname=tap0,script=''

I encountered the same problem (should be common to several
frontends, e.g. e100, eepro100, virtio-net, xen_nic):

in net/tap.c :: tap_send(), if qemu_send_packet_async() returns 0
(e.g. because the NIC has no buffers available)
traffic stops, despite the fact that the frontend will try to pull
queued packets when the receive ring is updated.

Upon investigation, it turns out that the backend code does

    size = qemu_send_packet_async(&s->nc, buf, size, tap_send_completed);
    if (size == 0) {
        tap_read_poll(s, 0);

and the arguments are

        s->nc.name = "tap.0"
        s->nc.peer->name = "hub0port1"
        s->nc.send_queue = 0x7f40b2f61e20
        s->nc.peer->send_queue = 0x7f40b2f63690 <--- enqueued here

whereis the frontend is trying to pull from a different queue

    qemu_flush_queued_packets(&s->nic->nc);

with arguments

        s->nic->nc.name = "e1000.0"
        s->nic->nc.peer->name = "hub0port0" <--- try to flush this
        s->nic->nc.send_queue = 0x7f40b3008ae0
        s->nic->nc.peer->send_queue = 0x7f40b2f63660


Note, regular traffic flows correctly across the hub,
but qemu_flush_queued_packets() seems to try and pull
from the wrong place.

Any idea how to fix this (other than the inefficient solution
of leaving read_poll=1 in the frontend)

        cheers
        luigi