[Qemu-devel] irq latency and tcg

[Qemu-devel] irq latency and tcg

[Artyom Tarasenko]

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?

Artyom

Re: [Qemu-devel] irq latency and tcg

[Paul Brook]

On Monday 07 December 2009, Artyom Tarasenko 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?

Interrupts generally only trigger at branch instructions, or similar.

Using -icount should give you precise interrupt delivery.

Paul

Re: [Qemu-devel] irq latency and tcg

[Artyom Tarasenko]

2009/12/7 Paul Brook <paul@codesourcery.com>:
> On Monday 07 December 2009, Artyom Tarasenko 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?
>
> Interrupts generally only trigger at branch instructions, or similar.
>
> Using -icount should give you precise interrupt delivery.

That's what I thought, but as I reported a few days ago, I couldn't
find a good value for icount when using OBP.
I tried a few values but keep getting "qemu: fatal: Raised interrupt
while not in I/O function".
Also I got a report from other person where qemu crashed with another
message: "qemu: fatal: Trap 0x29 while interrupts disabled".

What could be a good value for -icount? Is it host-cpu specific? Isn't
it a bug that qemu crashes [at least] on some icount values?

Re: [Qemu-devel] irq latency and tcg

[Paul Brook]

> > Using -icount should give you precise interrupt delivery.
> 
> That's what I thought, but as I reported a few days ago, I couldn't
> find a good value for icount when using OBP.
> I tried a few values but keep getting "qemu: fatal: Raised interrupt
> while not in I/O function".

That's almost certainly a bug in the sparc backend.

Paul

[Qemu-devel] Re: irq latency and tcg

[Blue Swirl]

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.

[Qemu-devel] Re: irq latency and tcg

[Artyom Tarasenko]

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?

[Qemu-devel] Re: irq latency and tcg

[Blue Swirl]

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?

[Qemu-devel] Re: irq latency and tcg

[Paul Brook]

> 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?

Not really.  With -icount we're trying to achieve deterministic behavior[1]. 
When icount is disabled a few extra instructions interrupt latency is the 
least of your problems.

I guess with in-core peripherals you may be able to accurately predict 
interrupt response. However for the vast majority of cases I wouldn't be 
surprised if real hardware has a few cycles latency anyway.

Paul

[1] Even with -icount, qemu is still a long way from being cycle accurate. The 
goal is to give reproducible and consistent results. Actual realtime 
characteristics are still likely to be very different from real hardware.

Paul