From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RfqyL-00036g-88 for qemu-devel@nongnu.org; Wed, 28 Dec 2011 05:43:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RfqyK-0000v0-6j for qemu-devel@nongnu.org; Wed, 28 Dec 2011 05:43:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26623) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RfqyJ-0000uw-VG for qemu-devel@nongnu.org; Wed, 28 Dec 2011 05:43:00 -0500 Message-ID: <4EFAF2B0.2090308@redhat.com> Date: Wed, 28 Dec 2011 12:42:56 +0200 From: Avi Kivity MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] interrupt handling in qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xin Tong Cc: qemu-devel On 12/28/2011 01:12 AM, Xin Tong wrote: > QEMU does not exit and handle interrupt within translation blocks. it > only exits after the translation block is finished. Assuming a > translation block is very long, is it possible that QEMU could have > exceeded the interrupt's "timing window" and yields unexpected > behavior. > > The reason I ask is that I am searching for alternatives to QEMU > current way of handling interrupt (unlink translation blocks on > interrupt). However, an obvious approach - checking for interrupt in > every basic block, seems to be too heavy ( too many tb enters/exits > ). Maybe checking interrupt in a few basic blocks might be better, but > what is a good measure for the number of basic blocks to execute > before checking for interrupt ? > It's possible to check for an interrupt before every instruction, without any overhead: - when a signal arrives, check the instruction pointer. If it points outside tcg code, set a flag and return. - consult a table indexed by the instruction pointer, that gives the number of bytes to the next guest instruction boundary - if nonzero, set a breakpoint at that boundary, and resume - remove the breakpoint (if set) - adjust the TB to return on the current instruction pointer - return -- error compiling committee.c: too many arguments to function