From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rfws9-0001TL-6S for qemu-devel@nongnu.org; Wed, 28 Dec 2011 12:01:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rfws6-0000Eh-Sl for qemu-devel@nongnu.org; Wed, 28 Dec 2011 12:01:00 -0500 Received: from mail-tul01m020-f173.google.com ([209.85.214.173]:63871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rfws6-0000Eb-GT for qemu-devel@nongnu.org; Wed, 28 Dec 2011 12:00:58 -0500 Received: by obcwp18 with SMTP id wp18so9227801obc.4 for ; Wed, 28 Dec 2011 09:00:57 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4EFB05C5.6000704@redhat.com> References: <4EFAF2B0.2090308@redhat.com> <4EFB05C5.6000704@redhat.com> Date: Wed, 28 Dec 2011 10:00:57 -0700 Message-ID: From: Xin Tong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] interrupt handling in qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity , Peter Maydell Cc: qemu-devel My main concern here is not how timely the interrupts can be handled, i am more interested in reducing the number of TB enters/exits due to interrupt. Returning to qemu mainloop requires saving and restoring register contexts which are expensive, what i am thinking is that can we check and handle interrupts every few TBs executed. But the drawback is that I do not know how many TBs would be a good number such that the interrupts do not get delayed too much. Thanks On Wed, Dec 28, 2011 at 5:04 AM, Avi Kivity wrote: > On 12/28/2011 01:40 PM, Peter Maydell wrote: >> On 28 December 2011 10:42, Avi Kivity wrote: >> > 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 >> >> This assumes you have hardware breakpoints on your host, so >> it's not portable. > > You could also use software breakpoints. =A0Or just temporarily replace > the host instruction on the next guest instruction boundary with a return= . > >> (You also need to add a check-and-handle-flag for every return >> from a helper function to TCG code, > > ah yes - didn't consider that. > > you could put all helper in their own section, an do something around > that - but that assumes no callouts from helpers to the standard library. > >> and of course you need to >> actually create the instruction-boundary table. > > This should be well amortized. > >> These are both >> overheads.) > > -- > error compiling committee.c: too many arguments to function >