From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NAA2f-00058R-IR for qemu-devel@nongnu.org; Mon, 16 Nov 2009 17:27:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NAA2b-00056k-MZ for qemu-devel@nongnu.org; Mon, 16 Nov 2009 17:27:25 -0500 Received: from [199.232.76.173] (port=32856 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NAA2b-00056S-Ba for qemu-devel@nongnu.org; Mon, 16 Nov 2009 17:27:21 -0500 Received: from mail2.shareable.org ([80.68.89.115]:59781) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NAA2a-0002EU-Si for qemu-devel@nongnu.org; Mon, 16 Nov 2009 17:27:21 -0500 Date: Mon, 16 Nov 2009 22:27:18 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH] sparc32 irq clearing (guest Solaris performance+NetBSD) fix Message-ID: <20091116222718.GA12063@shareable.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: Blue Swirl , qemu-devel Artyom Tarasenko wrote: > 2009/11/15 Blue Swirl : > > On Sun, Nov 15, 2009 at 1:15 AM, Artyom Tarasenko > > wrote: > >> 2009/11/14 Blue Swirl : > >>> On Sat, Nov 14, 2009 at 3:03 AM, Artyom Tarasenko > >>> 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