On Wed, Dec 9, 2009 at 2:30 PM, Artyom Tarasenko <atar4q...@googlemail.com> wrote: > 2009/12/7 Blue Swirl <blauwir...@gmail.com>: >> On Mon, Dec 7, 2009 at 3:30 PM, Artyom Tarasenko >> <atar4q...@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?
