Package: qemu-kvm Version: 1.1.2+dfsg-2 Severity: normal Tags: upstream >From upstream qemu commit series intro message (http://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01594.html):
---- When the guests replenish the receive ring buffer, the network device should flush its queue of pending packets. This is done with qemu_flush_queued_packets, and patches 2+3 add the missing call to two drivers, e1000 and xen. More may come later---no time to test them now. However, the device should not just retry delivery of packets that were already read from the tap device, it should also try to read more packets from the tap device. The latter requires a qemu_notify_event to force recomputation of the fd_sets. virtio already does this, but it is a layering violation; patch 1 moves the call from virtio to the network subsystem, so that e1000 and xen will then get it for free. Paolo Bonzini (3): net: notify iothread after flushing queue e1000: flush queue whenever can_receive can go from false to true xen: flush queue when getting an event ---- This means, among other things, that it is possible for e1000 to stall under normal load, provided there's no other activity "around" the guest -- like (virtual) disk access, timers and so on - actions which causes internal qemu FD# watchers to re-initialize. In usual conditions, when the guest uses disk or has timers, the impact can be very low. But for certain workload, like (virtual) diskless router, this might be more problematic. There are 2 patches needed from upstream to fix this: 987a9b4800003567b1a47a379255e886a77d57ea net: notify iothread after flushing queue e8b4c680b41bd960ecccd9ff076b7b058e0afcd4 e1000: flush queue whenever can_receive can go from false to true (and also a98b140223d3a627eab7ee3ddec645bab630d756 for xen). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
