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