[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] interrupt handling in qemu

From: Xin Tong
Subject: Re: [Qemu-devel] interrupt handling in qemu
Date: Wed, 28 Dec 2011 10:00:57 -0700

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.


On Wed, Dec 28, 2011 at 5:04 AM, Avi Kivity <address@hidden> wrote:
> On 12/28/2011 01:40 PM, Peter Maydell wrote:
>> On 28 December 2011 10:42, Avi Kivity <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]