[Qemu-devel] Re: irq latency and tcg

[Blue Swirl <blauwirbel@gmail.com>]

On Wed, Dec 9, 2009 at 2:30 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> 2009/12/7 Blue Swirl <blauwirbel@gmail.com>:
>> On Mon, Dec 7, 2009 at 3:30 PM, Artyom Tarasenko
>> <atar4qemu@googlemail.com> wrote:
>>> Can it be that qemu (-system-sparc in my case, but I guess it's more
>>> or less similar on all platforms) reacts to irqs slower than a real
>>> hardware due to tcg optimizations?
>>>
>>> I see one test pattern which fails on qemu:
>>>
>>> <cause an interrupt>
>>> nop * N
>>> <check whether the interrupt happened>
>>>
>>> What I observe is that the proper interrupt does take a place, but
>>> after the check, so no-one expects it anymore.
>>> Is there a way to reduce the interrupt latency? Or maybe there is a
>>> good substitute to a nop*N, so that irq would definitely get through
>>> in the mean time?
>>
>> On Sparc, nops do not generate any code at all.
>
> But "qemu: fatal: Raised interrupt while not in I/O function" is still
> a bug, right?

According to comment in exec-all.h:
/* Deterministic execution requires that IO only be performed on the last
   instruction of a TB so that interrupts take effect immediately.  */

Sparc generator must then violate this assumption. Is the assumption
valid also when not using icount and should the check be enabled for
all cases, not just icount?