From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NA9Wf-0001eH-5o for qemu-devel@nongnu.org; Mon, 16 Nov 2009 16:54:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NA9Wa-0001df-EE for qemu-devel@nongnu.org; Mon, 16 Nov 2009 16:54:20 -0500 Received: from [199.232.76.173] (port=36561 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NA9Wa-0001dc-B9 for qemu-devel@nongnu.org; Mon, 16 Nov 2009 16:54:16 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:42108) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NA9WZ-000695-RK for qemu-devel@nongnu.org; Mon, 16 Nov 2009 16:54:16 -0500 Received: by yxe26 with SMTP id 26so5026117yxe.4 for ; Mon, 16 Nov 2009 13:54:14 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Mon, 16 Nov 2009 23:53:54 +0200 Message-ID: Content-Type: multipart/mixed; boundary=0016e68e811ae3436e0478840cea Subject: [Qemu-devel] Re: [PATCH] sparc32 irq clearing (guest Solaris performance+NetBSD) fix List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel --0016e68e811ae3436e0478840cea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 16, 2009 at 7:19 PM, Artyom Tarasenko wrote: > 2009/11/16 Blue Swirl : >> On Mon, Nov 16, 2009 at 1:47 PM, 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/NCR= 89C105.txt >>>>>>> >>>>>>> Interrupts are cleared by disabling and then re-enabling them. >>>>>>> This patch implements the specified behaviour. The most visible eff= ects: >>>>>> >>>>>> 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") beh= avior? ;-) >>>> >>>> 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 =C2=A0in the moment of re-enabling (your version, s= ort 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. >> >> Still, this is user documentation, not implementation specification. >> I'm open to both versions, if they work. >> >>>> 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". >>> >>> >>>> 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. I think that's the way the interrupts are >>> handled at least under x86. >> >> It's a must on x86, because the interrupts are edge triggered. > > I don't know, how the real sun4m reacts in the case where irq stays > on, not being cleared. > It can not be though that it would try to process irq for every next > tick. The CPU must have some time to clear the pending irq, so it must > be edge triggered too, at least in a way. This patch makes the interrupts latch: ignore source clearing the interrupt. It seems be ~okay for my usual test setup, but does not help NetBSD 1.3.3. Some other NetBSD tests are changed, but they crashed before. --0016e68e811ae3436e0478840cea Content-Type: application/x-patch; name="0001-Sparc32-latch-incoming-interrupts.patch" Content-Disposition: attachment; filename="0001-Sparc32-latch-incoming-interrupts.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g23rs67d0 RnJvbSBiZjhjMzgxYzRjNmY3MTQwZGRjNzM4NjVlYmE2NDY0MGY0Yzc1MzUyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCbHVlIFN3aXJsIDxibGF1d2lyYmVsQGdtYWlsLmNvbT4KRGF0 ZTogTW9uLCAxNiBOb3YgMjAwOSAyMTo0ODo1MyArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIFNwYXJj MzI6IGxhdGNoIGluY29taW5nIGludGVycnVwdHMKClNpZ25lZC1vZmYtYnk6IEJsdWUgU3dpcmwg PGJsYXV3aXJiZWxAZ21haWwuY29tPgotLS0KIGh3L3NsYXZpb19pbnRjdGwuYyB8ICAgMTEgKyst LS0tLS0tLS0KIDEgZmlsZXMgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCA5IGRlbGV0aW9ucygt KQoKZGlmZiAtLWdpdCBhL2h3L3NsYXZpb19pbnRjdGwuYyBiL2h3L3NsYXZpb19pbnRjdGwuYwpp bmRleCA5YWZmODkyLi5hNjdkNWM5IDEwMDY0NAotLS0gYS9ody9zbGF2aW9faW50Y3RsLmMKKysr IGIvaHcvc2xhdmlvX2ludGN0bC5jCkBAIC0xODgsOCArMTg4LDggQEAgc3RhdGljIHZvaWQgc2xh dmlvX2ludGN0bG1fbWVtX3dyaXRlbCh2b2lkICpvcGFxdWUsIHRhcmdldF9waHlzX2FkZHJfdCBh ZGRyLAogICAgIGNhc2UgMzogLy8gc2V0IChkaXNhYmxlLCBjbGVhciBwZW5kaW5nKQogICAgICAg ICAvLyBGb3JjZSBjbGVhciB1bnVzZWQgYml0cwogICAgICAgICB2YWwgJj0gTUFTVEVSX0lSUV9N QVNLOwotICAgICAgICBzLT5pbnRyZWdtX2Rpc2FibGVkIHw9IHZhbDsKICAgICAgICAgcy0+aW50 cmVnbV9wZW5kaW5nICY9IH52YWw7CisgICAgICAgIHMtPmludHJlZ21fZGlzYWJsZWQgfD0gdmFs OwogICAgICAgICBzbGF2aW9fY2hlY2tfaW50ZXJydXB0cyhzLCAxKTsKICAgICAgICAgRFBSSU5U RigiRGlzYWJsZWQgbWFzdGVyIGlycSBtYXNrICV4LCBjdXJtYXNrICV4XG4iLCB2YWwsCiAgICAg ICAgICAgICAgICAgcy0+aW50cmVnbV9kaXNhYmxlZCk7CkBAIC0zMzgsMTUgKzMzOCw4IEBAIHN0 YXRpYyB2b2lkIHNsYXZpb19zZXRfaXJxKHZvaWQgKm9wYXF1ZSwgaW50IGlycSwgaW50IGxldmVs KQogICAgICAgICAgICAgICAgICAgICBzLT5zbGF2ZXNbaV0uaW50cmVnX3BlbmRpbmcgfD0gMSA8 PCBwaWw7CiAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgfQotICAgICAgICB9IGVsc2Ug ewotICAgICAgICAgICAgcy0+aW50cmVnbV9wZW5kaW5nICY9IH5tYXNrOwotICAgICAgICAgICAg aWYgKHBpbCA9PSAxNSkgewotICAgICAgICAgICAgICAgIGZvciAoaSA9IDA7IGkgPCBNQVhfQ1BV UzsgaSsrKSB7Ci0gICAgICAgICAgICAgICAgICAgIHMtPnNsYXZlc1tpXS5pbnRyZWdfcGVuZGlu ZyAmPSB+KDEgPDwgcGlsKTsKLSAgICAgICAgICAgICAgICB9Ci0gICAgICAgICAgICB9CisgICAg ICAgICAgICBzbGF2aW9fY2hlY2tfaW50ZXJydXB0cyhzLCAxKTsKICAgICAgICAgfQotICAgICAg ICBzbGF2aW9fY2hlY2tfaW50ZXJydXB0cyhzLCAxKTsKICAgICB9CiB9CiAKLS0gCjEuNS42LjUK Cg== --0016e68e811ae3436e0478840cea--