From: Thomas Gleixner <tglx@linutronix.de> To: "Eric W. Biederman" <ebiederm@xmission.com>, Bjorn Helgaas <helgaas@kernel.org> Cc: linux-pci@vger.kernel.org, kernelfans@gmail.com, andi@firstfloor.org, hpa@zytor.com, bhe@redhat.com, x86@kernel.org, okaya@kernel.org, mingo@redhat.com, jay.vosburgh@canonical.com, dyoung@redhat.com, gavin.guo@canonical.com, "Guilherme G. Piccoli" <gpiccoli@canonical.com>, bp@alien8.de, bhelgaas@google.com, shan.gavin@linux.alibaba.com, "Rafael J. Wysocki" <rjw@rjwysocki.net>, kernel@gpiccoli.net, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, ddstreet@canonical.com, lukas@wunner.de, vgoyal@redhat.com Subject: Re: [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks Date: Sun, 15 Nov 2020 16:11:43 +0100 [thread overview] Message-ID: <874klqac40.fsf@nanos.tec.linutronix.de> (raw) In-Reply-To: <87sg9almmg.fsf@x220.int.ebiederm.org> On Sun, Nov 15 2020 at 08:29, Eric W. Biederman wrote: > ebiederm@xmission.com (Eric W. Biederman) writes: > For ordinary irqs you can have this with level triggered irqs > and the kernel has code that will shutdown the irq at the ioapic > level. Then the kernel continues by polling the irq source. > > I am still missing details but my first question is can our general > solution to screaming level triggered irqs apply? No. > How can edge triggered MSI irqs be screaming? > > Is there something we can do in enabling the APICs or IOAPICs that > would allow this to be handled better. My memory when we enable > the APICs and IOAPICs we completely clear the APIC entries and so > should be disabling sources. Yes, but MSI has nothing to do with APIC/IOAPIC > Is the problem perhaps that we wind up using an APIC entry that was > previously used for the MSI interrupt as something else when we > reprogram them? Even with this why doesn't the generic code > to stop screaming irqs apply here? Again. No. The problem cannot be solved at the APIC level. The APIC is the receiving end of MSI and has absolutely no control over it. An MSI interrupt is a (DMA) write to the local APIC base address 0xfeexxxxx which has the target CPU and control bits encoded in the lower bits. The written data is the vector and more control bits. The only way to stop that is to shut it up at the PCI device level. Assume the following situation: - PCI device has MSI enabled and a valid target vector assigned - Kernel crashes - Kdump kernel starts - PCI device raises interrupts which result in the MSI write - Kdump kernel enables interrupts and the pending vector is raised in the CPU. - The CPU has no interrupt descriptor assigned to the vector and does not even know where the interrupt originated from. So it treats it like any other spurious interrupt to an unassigned vector, emits a ratelimited message and ACKs the interrupt at the APIC. - PCI device behaves stupid and reraises the interrupt for whatever reason. - Lather, rinse and repeat. Unfortunately there is no way to tell the APIC "Mask vector X" and the dump kernel does neither know which device it comes from nor does it have enumerated PCI completely which would reset the device and shutup the spew. Due to the interrupt storm it does not get that far. Thanks, tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de> To: "Eric W. Biederman" <ebiederm@xmission.com>, Bjorn Helgaas <helgaas@kernel.org> Cc: linux-pci@vger.kernel.org, kernelfans@gmail.com, andi@firstfloor.org, hpa@zytor.com, bhe@redhat.com, x86@kernel.org, okaya@kernel.org, mingo@redhat.com, jay.vosburgh@canonical.com, dyoung@redhat.com, vgoyal@redhat.com, "Guilherme G. Piccoli" <gpiccoli@canonical.com>, bp@alien8.de, bhelgaas@google.com, shan.gavin@linux.alibaba.com, kexec@lists.infradead.org, kernel@gpiccoli.net, "Rafael J. Wysocki" <rjw@rjwysocki.net>, linux-kernel@vger.kernel.org, ddstreet@canonical.com, lukas@wunner.de, gavin.guo@canonical.com Subject: Re: [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks Date: Sun, 15 Nov 2020 16:11:43 +0100 [thread overview] Message-ID: <874klqac40.fsf@nanos.tec.linutronix.de> (raw) In-Reply-To: <87sg9almmg.fsf@x220.int.ebiederm.org> On Sun, Nov 15 2020 at 08:29, Eric W. Biederman wrote: > ebiederm@xmission.com (Eric W. Biederman) writes: > For ordinary irqs you can have this with level triggered irqs > and the kernel has code that will shutdown the irq at the ioapic > level. Then the kernel continues by polling the irq source. > > I am still missing details but my first question is can our general > solution to screaming level triggered irqs apply? No. > How can edge triggered MSI irqs be screaming? > > Is there something we can do in enabling the APICs or IOAPICs that > would allow this to be handled better. My memory when we enable > the APICs and IOAPICs we completely clear the APIC entries and so > should be disabling sources. Yes, but MSI has nothing to do with APIC/IOAPIC > Is the problem perhaps that we wind up using an APIC entry that was > previously used for the MSI interrupt as something else when we > reprogram them? Even with this why doesn't the generic code > to stop screaming irqs apply here? Again. No. The problem cannot be solved at the APIC level. The APIC is the receiving end of MSI and has absolutely no control over it. An MSI interrupt is a (DMA) write to the local APIC base address 0xfeexxxxx which has the target CPU and control bits encoded in the lower bits. The written data is the vector and more control bits. The only way to stop that is to shut it up at the PCI device level. Assume the following situation: - PCI device has MSI enabled and a valid target vector assigned - Kernel crashes - Kdump kernel starts - PCI device raises interrupts which result in the MSI write - Kdump kernel enables interrupts and the pending vector is raised in the CPU. - The CPU has no interrupt descriptor assigned to the vector and does not even know where the interrupt originated from. So it treats it like any other spurious interrupt to an unassigned vector, emits a ratelimited message and ACKs the interrupt at the APIC. - PCI device behaves stupid and reraises the interrupt for whatever reason. - Lather, rinse and repeat. Unfortunately there is no way to tell the APIC "Mask vector X" and the dump kernel does neither know which device it comes from nor does it have enumerated PCI completely which would reset the device and shutup the spew. Due to the interrupt storm it does not get that far. Thanks, tglx _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2020-11-15 15:12 UTC|newest] Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-18 18:37 [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks Guilherme G. Piccoli 2018-10-18 18:37 ` Guilherme G. Piccoli 2018-10-18 18:37 ` [PATCH 2/3] x86/PCI: Export find_cap() to be used in early PCI code Guilherme G. Piccoli 2018-10-18 18:37 ` Guilherme G. Piccoli 2018-10-18 18:37 ` [PATCH 3/3] x86/quirks: Add parameter to clear MSIs early on boot Guilherme G. Piccoli 2018-10-18 18:37 ` Guilherme G. Piccoli 2018-10-18 20:08 ` Sinan Kaya 2018-10-18 20:08 ` Sinan Kaya 2018-10-18 20:13 ` Guilherme G. Piccoli 2018-10-18 20:13 ` Guilherme G. Piccoli 2018-10-18 20:30 ` Sinan Kaya 2018-10-18 20:30 ` Sinan Kaya 2018-10-22 19:44 ` Guilherme G. Piccoli 2018-10-22 19:44 ` Guilherme G. Piccoli 2018-10-18 22:15 ` [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks Bjorn Helgaas 2018-10-18 22:15 ` Bjorn Helgaas 2018-10-22 20:35 ` Guilherme G. Piccoli 2018-10-22 20:35 ` Guilherme G. Piccoli 2018-10-23 17:03 ` Bjorn Helgaas 2018-10-23 17:03 ` Bjorn Helgaas 2020-11-06 13:14 ` Guilherme G. Piccoli 2020-11-06 13:14 ` Guilherme G. Piccoli 2020-11-13 16:46 ` Bjorn Helgaas 2020-11-13 16:46 ` Bjorn Helgaas 2020-11-13 23:31 ` Thomas Gleixner 2020-11-13 23:31 ` Thomas Gleixner 2020-11-13 23:40 ` Thomas Gleixner 2020-11-13 23:40 ` Thomas Gleixner 2020-11-14 20:39 ` Bjorn Helgaas 2020-11-14 20:39 ` Bjorn Helgaas 2020-11-14 20:58 ` Thomas Gleixner 2020-11-14 20:58 ` Thomas Gleixner 2020-11-14 21:22 ` Bjorn Helgaas 2020-11-14 21:22 ` Bjorn Helgaas 2020-11-15 14:05 ` Eric W. Biederman 2020-11-15 14:05 ` Eric W. Biederman 2020-11-15 14:29 ` Eric W. Biederman 2020-11-15 14:29 ` Eric W. Biederman 2020-11-15 15:11 ` Thomas Gleixner [this message] 2020-11-15 15:11 ` Thomas Gleixner 2020-11-15 17:01 ` Lukas Wunner 2020-11-15 19:18 ` Thomas Gleixner 2020-11-15 19:18 ` Thomas Gleixner 2020-11-15 20:46 ` Eric W. Biederman 2020-11-15 20:46 ` Eric W. Biederman 2020-11-16 20:31 ` Guilherme G. Piccoli 2020-11-16 20:31 ` Guilherme G. Piccoli 2020-11-16 21:45 ` Eric W. Biederman 2020-11-16 21:45 ` Eric W. Biederman 2020-11-16 21:49 ` Guilherme Piccoli 2020-11-16 21:49 ` Guilherme Piccoli 2020-11-17 0:19 ` Bjorn Helgaas 2020-11-17 0:19 ` Bjorn Helgaas 2020-11-17 1:06 ` Eric W. Biederman 2020-11-17 1:06 ` Eric W. Biederman 2020-11-17 9:53 ` Thomas Gleixner 2020-11-17 9:53 ` Thomas Gleixner 2020-11-17 12:19 ` David Woodhouse 2020-11-17 12:19 ` David Woodhouse 2020-11-17 19:34 ` Thomas Gleixner 2020-11-17 19:34 ` Thomas Gleixner 2020-11-17 22:25 ` Eric W. Biederman 2020-11-17 22:25 ` Eric W. Biederman 2020-11-17 12:04 ` Guilherme Piccoli 2020-11-17 12:04 ` Guilherme Piccoli 2020-11-18 21:05 ` Bjorn Helgaas 2020-11-18 21:05 ` Bjorn Helgaas 2020-11-18 22:36 ` Guilherme Piccoli 2020-11-18 22:36 ` Guilherme Piccoli 2020-11-30 20:20 ` Bjorn Helgaas 2020-11-30 20:20 ` Bjorn Helgaas 2020-12-14 18:32 ` Guilherme Piccoli 2020-12-14 18:32 ` Guilherme Piccoli
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=874klqac40.fsf@nanos.tec.linutronix.de \ --to=tglx@linutronix.de \ --cc=andi@firstfloor.org \ --cc=bhe@redhat.com \ --cc=bhelgaas@google.com \ --cc=bp@alien8.de \ --cc=ddstreet@canonical.com \ --cc=dyoung@redhat.com \ --cc=ebiederm@xmission.com \ --cc=gavin.guo@canonical.com \ --cc=gpiccoli@canonical.com \ --cc=helgaas@kernel.org \ --cc=hpa@zytor.com \ --cc=jay.vosburgh@canonical.com \ --cc=kernel@gpiccoli.net \ --cc=kernelfans@gmail.com \ --cc=kexec@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=lukas@wunner.de \ --cc=mingo@redhat.com \ --cc=okaya@kernel.org \ --cc=rjw@rjwysocki.net \ --cc=shan.gavin@linux.alibaba.com \ --cc=vgoyal@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: linkBe 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.