All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic
Date: Tue, 11 Sep 2012 11:04:30 +0200	[thread overview]
Message-ID: <504EFE9E.3090503@web.de> (raw)
In-Reply-To: <alpine.LFD.2.00.1209110133120.8926@eddie.linux-mips.org>

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On 2012-09-11 02:49, Maciej W. Rozycki wrote:
> On Sun, 9 Sep 2012, Matthew Ogilvie wrote:
> 
>> This bug manifested itself when the guest was Microport UNIX
>> System V/386 v2.1 (ca. 1987), because it would sometimes mask
>> off IRQ14 in the slave IMR after it had already been asserted.
>> The master would still try to deliver an interrupt even though
>> IRQ2 had dropped again, resulting in a spurious interupt
>> (IRQ15) and a panicked UNIX kernel.
> 
>  That is quite weird actually -- from my experience the spurious vector is 
> never sent from a slave (quite understandably -- since the interrupt is 
> gone and no other is pending, the master has no reason to select a slave 
> to supply a vector and therefore supplies the spurious vector itself) and 
> therefore a spurious IRQ7 is always issued regardless of whether the 
> discarded request came from a slave or from the master.

As we do not clear IRQ14 in IRR of the slave nor do we clear IRQ2 of the
master, the master has a good reason to ask the slave for the vector.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@web.de>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Matthew Ogilvie <mmogilvi_qemu@miniinfo.net>,
	kvm@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic
Date: Tue, 11 Sep 2012 11:04:30 +0200	[thread overview]
Message-ID: <504EFE9E.3090503@web.de> (raw)
In-Reply-To: <alpine.LFD.2.00.1209110133120.8926@eddie.linux-mips.org>

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On 2012-09-11 02:49, Maciej W. Rozycki wrote:
> On Sun, 9 Sep 2012, Matthew Ogilvie wrote:
> 
>> This bug manifested itself when the guest was Microport UNIX
>> System V/386 v2.1 (ca. 1987), because it would sometimes mask
>> off IRQ14 in the slave IMR after it had already been asserted.
>> The master would still try to deliver an interrupt even though
>> IRQ2 had dropped again, resulting in a spurious interupt
>> (IRQ15) and a panicked UNIX kernel.
> 
>  That is quite weird actually -- from my experience the spurious vector is 
> never sent from a slave (quite understandably -- since the interrupt is 
> gone and no other is pending, the master has no reason to select a slave 
> to supply a vector and therefore supplies the spurious vector itself) and 
> therefore a spurious IRQ7 is always issued regardless of whether the 
> discarded request came from a slave or from the master.

As we do not clear IRQ14 in IRR of the slave nor do we clear IRQ2 of the
master, the master has a good reason to ask the slave for the vector.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

  parent reply	other threads:[~2012-09-11  9:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-10  1:29 [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic Matthew Ogilvie
2012-09-10  1:29 ` [Qemu-devel] " Matthew Ogilvie
2012-09-10  1:29 ` [PATCH 2/2] KVM: i8259: refactor pic_set_irq level logic Matthew Ogilvie
2012-09-10  1:29   ` [Qemu-devel] " Matthew Ogilvie
2012-09-11  0:49 ` [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic Maciej W. Rozycki
2012-09-11  0:49   ` [Qemu-devel] " Maciej W. Rozycki
2012-09-11  4:54   ` Matthew Ogilvie
2012-09-11  4:54     ` [Qemu-devel] " Matthew Ogilvie
2012-09-11 11:53     ` Maciej W. Rozycki
2012-09-11 11:53       ` [Qemu-devel] " Maciej W. Rozycki
2012-09-11  9:04   ` Jan Kiszka [this message]
2012-09-11  9:04     ` Jan Kiszka
2012-09-12  8:01 ` Avi Kivity
2012-09-12  8:01   ` Avi Kivity
2012-09-12  8:48   ` Jan Kiszka
2012-09-12  8:48     ` [Qemu-devel] " Jan Kiszka
2012-09-12  8:51     ` Avi Kivity
2012-09-12  8:51       ` [Qemu-devel] " Avi Kivity
2012-09-12  8:57       ` Jan Kiszka
2012-09-12  8:57         ` Jan Kiszka
2012-09-12  9:02         ` Avi Kivity
2012-09-12  9:02           ` Avi Kivity
2012-09-13  5:49         ` Matthew Ogilvie
2012-09-13  5:49           ` [Qemu-devel] " Matthew Ogilvie
2012-09-13 13:41           ` Maciej W. Rozycki
2012-09-13 13:41             ` Maciej W. Rozycki
2012-09-13 13:49             ` Jan Kiszka
2012-09-13 13:49               ` Jan Kiszka
2012-09-13 13:55           ` Jan Kiszka
2012-09-13 13:55             ` Jan Kiszka
2012-09-13 15:48             ` Maciej W. Rozycki
2012-09-13 15:48               ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=504EFE9E.3090503@web.de \
    --to=jan.kiszka@web.de \
    --cc=kvm@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=mmogilvi_qemu@miniinfo.net \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.