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?
