Re: [Qemu-devel] Re: [PATCH] sparc32 irq clearing (guest Solaris performance+NetBSD) fix

[Jamie Lokier <jamie@shareable.org>]

Artyom Tarasenko wrote:
> 2009/11/15 Blue Swirl <blauwirbel@gmail.com>:
> > On Sun, Nov 15, 2009 at 1:15 AM, Artyom Tarasenko
> > <atar4qemu@googlemail.com> wrote:
> >> 2009/11/14 Blue Swirl <blauwirbel@gmail.com>:
> >>> On Sat, Nov 14, 2009 at 3:03 AM, Artyom Tarasenko
> >>> <atar4qemu@googlemail.com> wrote:
> >>>> According to NCR89C105 documentation
> >>>> http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR89C105.txt
> >>>>
> >>>> Interrupts are cleared by disabling and then re-enabling them.
> >>>> This patch implements the specified behaviour. The most visible effects:
> >>>
> >>> I think the current version also implements this behaviour. The
> >>> difference is that now we clear on disable, with your version, the
> >>> interrupts are cleared when re-enabling them.
> >>
> >> Doesn't this imply that the current version does not implement this
> >> ("Interrupts are cleared by disabling and then re-enabling them") behavior? ;-)
> >
> > The specification only says that the sequence disable-enable clears
> > interrupts, but not which of these is true:
> > - clearing happens in the moment of disabling (and interrupts after
> > that are not cleared, current version)
> > - clearing happens  in the moment of re-enabling (your version, sort of)
> > - clearing happens in both cases (lose interrupts)
> 
> English is not my native language, but fwiw I think "and then
> re-enabling" can only be the second variant. Without "then" it could
> be either one or three. And if the first variant is what they really
> meant, the part with "and then" is totally redundant and misleading.

It could also be a fourth:

- Clearing happens continuously _during_ the time the interrupt is disabled.

Note that neither this, nor the third possibility, have to cause lost
interrupts - that depends on whether the code which enables interrupts
checks for them being pending after enabling them, or checks the
devices generating them.

> > It's also interesting to think what happens between the interrupt
> > controller and the devices. Clearing an interrupt at controller level
> > does not clear the interrupt condition at the device. Aren't the
> > interrupts level triggered on Sparc, so the interrupt is still posted?
> > Is the interrupt actually masked by clearing until the level is
> > deactivated?
> 
> Looks unlikely to me. In the book "Panic! Unix system crash dump
> analysis" the authors write that the first thing interrupt handler has
> to do is disable the interrupt, and yes wrting "unix" they mean
> "SunOS/Solaris".
>
> That's also what I observe debugging the Solaris kernel code
> (Solaris kernel debugger is a really powerful tool).
> Looks like interrupts can be shared between devices, so the general
> handler disables the interrupt and then calls multiple device-specific
> handlers sequentially and checks if any of then claims the interrupt.
> If no one does it writes the message "Spurious interrupt %d\n".

That's consistent with level triggered interrupts, and may require the
interrupt to be cleared at the device before it is re-enabled at the
interrupt controller.

> > Or maybe the controller latches the interrupt so that even after the
> > device releases the interrupt line, interrupt is still active towards
> > the CPU. Then the clearing would make sense.
> 
> Looks very realistic to me.

>From what you said above about Solaris, I don't think you can
distinguish between interrupts being asserted only while a device
continues to assert it, and interrupts remaining asserted after the
device stops.

-- Jamie