[Qemu-devel] Re: sparc32 double "Set CPU IRQ 14"

[Blue Swirl <blauwirbel@gmail.com>]

On Thu, Aug 6, 2009 at 12:35 PM, Artyom
Tarasenko<atar4qemu@googlemail.com> wrote:
> I observe double "Set CPU IRQ 14" in the log.  I don't see how  the
> real harware would be able to generate the same irq twice, without
> resetting it. I put a printf in cpuexec.c:
>
> #elif defined(TARGET_SPARC)
>                    if ((interrupt_request & CPU_INTERRUPT_HARD) &&
>                        cpu_interrupts_enabled(env)) {
>                        int pil = env->interrupt_index & 15;
>                        int type = env->interrupt_index & 0xf0;
>
>                        if (((type == TT_EXTINT) &&
>                             (pil == 15 || pil > env->psrpil)) ||
>                            type != TT_EXTINT) {
>                            env->interrupt_request &= ~CPU_INTERRUPT_HARD;
>                            env->exception_index = env->interrupt_index;
>                            do_interrupt(env);
>                            env->interrupt_index = 0;
> #if !defined(CONFIG_USER_ONLY)
>               printf("cpuexec calls cpu_check_irqs\n");
>                            cpu_check_irqs(env);
> #endif
>                        next_tb = 0;
>                        }
>
>
> And now my log looks like this:
>
> CPUIRQ: Raise CPU IRQ 14
> CPUIRQ: Set CPU IRQ 14
> cpuexec calls cpu_check_irqs
> CPUIRQ: Set CPU IRQ 14
>
> Does it look like cpuexec does an unnecessary call of cpu_check_irqs ?
>
> I've removed this call, and see no difference: OBP works the same,
> OpenBIOS too, NetBSD boot log also seems to be the same.
>
> What this call is needed for?

IIRC it's there to handle this situation:
1) interrupts are masked by the CPU up to some level (e.g. 12)
2) some lower level interrupts are active (level 10), but due to the
mask CPU ignores them
3) a higher level interrupt arrives (level 14) and is delivered to the CPU
4) after the trap handling has started, the lower level (10) interrupt
should be active again but it's still being ignored
5) when the interrupt mask is lowered, the lower level interrupt (10)
should generate a trap

But step #4 does not look correct, especially the call to
cpu_check_irqs. The use of env->interrupt_index should be redesigned,
maybe the interrupt mask could be recalculated in helper_wrpsr
instead. Then step #4 would happen at the right time.