> Paul Brook wrote: > >> But anyway, this flow control mechanism is buggy - what if instead of > >> an interface down, you just have a *slow* guest? That should not push > >> back so much that it makes other guests networking with each other > >> slow down. > > > > The OP described multiple guests connected via a host bridge. In this > > case it is entirely the host's responsibility to arbitrate between > > multiple guests. If one interface can block the bridge simply by failing > > to respond in a timely manner then this is a serious bug or > > misconfiguration of your host bridge. > > It's not the bridge, I think it's limited to the tun driver as bridge > participant and how it is configured/used by QEMU.
If one tap interface can prevent correct operation of another by failing to read data, then this is clearly a host kernel bug. I've no idea whether it's a bug in the TAP implementation (e.g. shared queue between independent devices), a bug in the bridging implementation (drops unrelated packets when one port is slow), or some interaction between the two, but it's definitely not a qemu bug. I'm sure there are plenty of ways to DoS a qemu instance, and prevent it reading data from its tap interface. How/whether this effects other unrelated processes on the host machine is not something qemu can or should know about. Paul
