Re: [Qemu-devel] interrupt handling in qemu

[Xin Tong <xerox.time.tech@gmail.com>]

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 <avi@redhat.com> wrote:
> 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
>