From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:48604)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RfsFL-0005so-2R
	for qemu-devel@nongnu.org; Wed, 28 Dec 2011 07:04:39 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RfsFJ-0006BM-UU
	for qemu-devel@nongnu.org; Wed, 28 Dec 2011 07:04:39 -0500
Received: from mx1.redhat.com ([209.132.183.28]:27054)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RfsFJ-0006BB-Me
	for qemu-devel@nongnu.org; Wed, 28 Dec 2011 07:04:37 -0500
Message-ID: <4EFB05C5.6000704@redhat.com>
Date: Wed, 28 Dec 2011 14:04:21 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <CALKntY1LimQ5Kim=OTC3POy1ycDvS6nMHsEsz9XpzLZHOYHKEA@mail.gmail.com>
	<4EFAF2B0.2090308@redhat.com>
	<CAFEAcA-agw7zaDLwK9agAKPo1wjWND2CV+_Jw2QqyGh=e+vjiA@mail.gmail.com>
In-Reply-To: <CAFEAcA-agw7zaDLwK9agAKPo1wjWND2CV+_Jw2QqyGh=e+vjiA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] interrupt handling in qemu
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel <qemu-devel@nongnu.org>, Xin Tong <xerox.time.tech@gmail.com>

On 12/28/2011 01:40 PM, Peter Maydell wrote:
> On 28 December 2011 10:42, Avi Kivity <avi@redhat.com> 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.  Or 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