[Top][All Lists]

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

Re: [Qemu-devel] interrupt handling in qemu

From: Avi Kivity
Subject: Re: [Qemu-devel] interrupt handling in qemu
Date: Wed, 28 Dec 2011 12:42:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

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

reply via email to

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