From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQQe0-0004Mv-It for qemu-devel@nongnu.org; Fri, 23 Jan 2009 13:20:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQQdy-0004La-Uj for qemu-devel@nongnu.org; Fri, 23 Jan 2009 13:20:40 -0500 Received: from [199.232.76.173] (port=39623 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQQdy-0004LX-OA for qemu-devel@nongnu.org; Fri, 23 Jan 2009 13:20:38 -0500 Received: from mx20.gnu.org ([199.232.41.8]:28518) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LQQdy-0005T5-9Q for qemu-devel@nongnu.org; Fri, 23 Jan 2009 13:20:38 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LQQdw-0005Qs-7C for qemu-devel@nongnu.org; Fri, 23 Jan 2009 13:20:36 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [6391] Fix nographic mode and VNC Date: Fri, 23 Jan 2009 18:20:31 +0000 References: <200901220423.23551.paul@codesourcery.com> <497890ED.6000109@codemonkey.ws> In-Reply-To: <497890ED.6000109@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901231820.32999.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , qemu-devel@nongnu.org > >> A second solution is to use a polling select() in cpu_exec. Since > >> you're adding a system call (and a rather heavy one) in the fast path, > >> this is going to likely hurt TCG performance. > > > > This won't work. If the guest really is in a tight loop then TB chaining > > means it will never exit translated code. > > But then signal delivery wouldn't either, right? That suggests that if > the guest is in a tight loop right now, QEMU will freeze. No. The signal handler calls cpu_interrupt, which unlinks the TBs. > There's a fair bit of code that is safe to run along side of TCG. If we > separate the locking for the device model code from every thing (the > monitor, vnc, sdl, etc.), then we could still let QEMU be responsive > even in such a condition. Maybe. You risk having to put an SMP safe lock in the MMIO handler, which would probably do bad things to performance. Many of the embedded targets don't have DMA capable peripherals, so we want to avoid making MMIO too expensive. kvm is a bit different because MMIO is already horribly expensive. Paul