All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Vitaly Kuznetsov <vkuznets@redhat.com>, x86@kernel.org
Cc: Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 1/2] x86/apic: Do not make an exception for PIC_CASCADE_IR when marking legacy irqs in irq_matrix
Date: Wed, 17 Mar 2021 22:40:45 +0100	[thread overview]
Message-ID: <878s6lxxuq.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <87blbhxyvk.fsf@nanos.tec.linutronix.de>

On Wed, Mar 17 2021 at 22:18, Thomas Gleixner wrote:

> On Wed, Mar 17 2021 at 21:14, Thomas Gleixner wrote:
>> On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
>> Even without looking at the machine I can tell you what's going on. MP
>> config or ACPI has a pin assigned to IRQ 2 which I've not seen before.
>> The code there is ignoring IRQ 2 because that's how the original code
>> worked as well as it is reserved for the PIC_CASCADE_IRQ which should
>> never fire and we actually want to catch an spurious interrupt on it.
>>
>> So depending on the overall configuration of that system and the
>> resulting delivery modes this might be ok, but I'm really nervous about
>> doing this wholesale as it might break old machines.
>>
>> Out of paranoia I'd rather ignore that IO/APIC pin completely if it
>> claims to be IRQ2. I assume there is no device connected to it at all,
>> right?
>
> Seems at some point we lost the 'ignore cascade IRQ' logic in
> IO/APIC. There is still a comment to that effect.
>
> Let me do some archaeology.

af174783b925 ("x86: I/O APIC: Never configure IRQ2")

has a very nice explanation why.

Back then the logic was quite different. All legacy PIC interrupts
(0-15) were bound to the legacy vectors at boot and never moved away.

There was a check in the back then setup routing which prevented the
IOAPIC routing of IRQ2 which got lost at some point. Haven't figured out
yet where this might be. Still digging in those ancient horrors.

Thanks,

        tglx


  reply	other threads:[~2021-03-17 21:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 11:30 [PATCH RFC 0/2] x86/apic: Avoid cm->allocated going negative in irq_matrix Vitaly Kuznetsov
2021-02-19 11:31 ` [PATCH RFC 1/2] x86/apic: Do not make an exception for PIC_CASCADE_IR when marking legacy irqs " Vitaly Kuznetsov
2021-03-17 20:14   ` Thomas Gleixner
2021-03-17 21:18     ` Thomas Gleixner
2021-03-17 21:40       ` Thomas Gleixner [this message]
2021-03-17 22:52         ` Thomas Gleixner
2021-03-18  8:47           ` Vitaly Kuznetsov
2021-03-18  8:29     ` Vitaly Kuznetsov
2021-03-18 10:10       ` Thomas Gleixner
2021-02-19 11:31 ` [PATCH RFC 2/2] genirq/matrix: WARN_ON_ONCE() when cm->allocated/m->total_allocated go negative Vitaly Kuznetsov
2021-03-17 20:38   ` Thomas Gleixner
2021-03-18  7:58     ` Vitaly Kuznetsov
2021-03-18 19:29       ` Thomas Gleixner
2021-03-19  9:59         ` Vitaly Kuznetsov
2021-03-11 10:19 ` [PATCH RFC 0/2] x86/apic: Avoid cm->allocated going negative in irq_matrix Vitaly Kuznetsov

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=878s6lxxuq.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.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.