From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1fmr-0002qj-KH for qemu-devel@nongnu.org; Tue, 13 Apr 2010 09:04:17 -0400 Received: from [140.186.70.92] (port=48389 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1fmV-0002fc-3y for qemu-devel@nongnu.org; Tue, 13 Apr 2010 09:04:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1flI-0000PM-EW for qemu-devel@nongnu.org; Tue, 13 Apr 2010 09:02:42 -0400 Received: from mx20.gnu.org ([199.232.41.8]:3198) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1flI-0000PG-BQ for qemu-devel@nongnu.org; Tue, 13 Apr 2010 09:02:40 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1O1flH-0001ia-OU for qemu-devel@nongnu.org; Tue, 13 Apr 2010 09:02:40 -0400 From: Paul Brook Subject: Re: [Qemu-devel] How to lock-up your tap-based VM network Date: Tue, 13 Apr 2010 14:02:24 +0100 References: <4BC34D95.7050804@siemens.com> <201004130020.13764.paul@codesourcery.com> <4BC463EA.8000201@siemens.com> In-Reply-To: <4BC463EA.8000201@siemens.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004131402.25982.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Jan Kiszka , Herbert Xu , Mark McLoughlin > 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