| commit | 9ded316d40ecaca487c70ac49fa9fec026562638 | |
| author | Alexey Kardashevskiy <aik@ozlabs.ru> | |
| Thu, 2 May 2013 20:22:03 +0000 (2 20:22 +0000) | ||
| committer | Alexander Graf <agraf@suse.de> | |
| Mon, 6 May 2013 15:17:00 +0000 (6 17:17 +0200) | ||
| tree | 4f71794a28cc56a9e7821df9a4c80b7b0d3e501e | treesnapshot (tar.gz zip) |
| parent | 798e100cdad964ed6b2efdbba6d30216640275bb | commitdiff |
spapr_llan: fix device reenabling
Normally, the "tap" device is polled by QEMU if a guest NIC can
receive packets. If a guest NIC is stopped during transfer (rmmod or
ifdown), it may still have packets in a queue which have to be send
to the guest before QEMU enables polling of a "tap" interface via
tap_update_fd_handler().
However the spapr_llan device was missing the qemu_flush_queued_packets()
call so the tap_send_completed() callback was never called and therefore
"tap" interface polling was not enabled ever.
The patch fixes this problem.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
Normally, the "tap" device is polled by QEMU if a guest NIC can
receive packets. If a guest NIC is stopped during transfer (rmmod or
ifdown), it may still have packets in a queue which have to be send
to the guest before QEMU enables polling of a "tap" interface via
tap_update_fd_handler().
However the spapr_llan device was missing the qemu_flush_queued_packets()
call so the tap_send_completed() callback was never called and therefore
"tap" interface polling was not enabled ever.
The patch fixes this problem.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
| hw/net/spapr_llan.c | diffblobblamehistory |