From: ebiederm@xmission.com (Eric W. Biederman) To: Bjorn Helgaas <helgaas@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de>, "Guilherme G. Piccoli" <gpiccoli@canonical.com>, linux-pci@vger.kernel.org, kexec@lists.infradead.org, x86@kernel.org, linux-kernel@vger.kernel.org, bhelgaas@google.com, dyoung@redhat.com, bhe@redhat.com, vgoyal@redhat.com, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, andi@firstfloor.org, lukas@wunner.de, okaya@kernel.org, kernelfans@gmail.com, ddstreet@canonical.com, gavin.guo@canonical.com, jay.vosburgh@canonical.com, kernel@gpiccoli.net, shan.gavin@linux.alibaba.com, "Rafael J. Wysocki" <rjw@rjwysocki.net> Subject: Re: [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks Date: Sun, 15 Nov 2020 08:05:05 -0600 [thread overview] Message-ID: <87v9e6n2b2.fsf@x220.int.ebiederm.org> (raw) In-Reply-To: <20201114212215.GA1194074@bjorn-Precision-5520> (Bjorn Helgaas's message of "Sat, 14 Nov 2020 15:22:15 -0600") Bjorn Helgaas <helgaas@kernel.org> writes: > [+cc Rafael for question about ACPI method for PCI host bridge reset] > > On Sat, Nov 14, 2020 at 09:58:08PM +0100, Thomas Gleixner wrote: >> On Sat, Nov 14 2020 at 14:39, Bjorn Helgaas wrote: >> > On Sat, Nov 14, 2020 at 12:40:10AM +0100, Thomas Gleixner wrote: >> >> On Sat, Nov 14 2020 at 00:31, Thomas Gleixner wrote: >> >> > On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote: >> >> >> pci_device_shutdown() still clears the Bus Master Enable bit if we're >> >> >> doing a kexec and the device is in D0-D3hot, which should also disable >> >> >> MSI/MSI-X. Why doesn't this solve the problem? Is this because the >> >> >> device causing the storm was in PCI_UNKNOWN state? >> >> > >> >> > That's indeed a really good question. >> >> >> >> So we do that on kexec, but is that true when starting a kdump kernel >> >> from a kernel crash? I doubt it. >> > >> > Ah, right, I bet that's it, thanks. The kdump path is basically this: >> > >> > crash_kexec >> > machine_kexec >> > >> > while the usual kexec path is: >> > >> > kernel_kexec >> > kernel_restart_prepare >> > device_shutdown >> > while (!list_empty(&devices_kset->list)) >> > dev->bus->shutdown >> > pci_device_shutdown # pci_bus_type.shutdown >> > machine_kexec >> > >> > So maybe we need to explore doing some or all of device_shutdown() in >> > the crash_kexec() path as well as in the kernel_kexec() path. >> >> The problem is that if the machine crashed anything you try to attempt >> before starting the crash kernel is reducing the chance that the crash >> kernel actually starts. > > Right. > >> Is there something at the root bridge level which allows to tell the >> underlying busses to shut up, reset or go into a defined state? That >> might avoid chasing lists which might be already unreliable. > > Maybe we need some kind of crash_device_shutdown() that does the > minimal thing to protect the kdump kernel from devices. The kdump kernel does not use any memory the original kernel uses. Which should be a minimal and fairly robust level of protection until the device drivers can be loaded and get ahold of things. > The programming model for conventional PCI host bridges and PCIe Root > Complexes is device-specific since they're outside the PCI domain. > There probably *are* ways to do those things, but you would need a > native host bridge driver or something like an ACPI method. I'm not > aware of an ACPI way to do this, but I added Rafael in case he is. > > A crash_device_shutdown() could do something at the host bridge level > if that's possible, or reset/disable bus mastering/disable MSI/etc on > individual PCI devices if necessary. Unless I am confused DMA'ing to memory that is not already in use is completely broken wether or not you are using the kdump kernel. Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman) To: 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, Thomas Gleixner <tglx@linutronix.de>, 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 08:05:05 -0600 [thread overview] Message-ID: <87v9e6n2b2.fsf@x220.int.ebiederm.org> (raw) In-Reply-To: <20201114212215.GA1194074@bjorn-Precision-5520> (Bjorn Helgaas's message of "Sat, 14 Nov 2020 15:22:15 -0600") Bjorn Helgaas <helgaas@kernel.org> writes: > [+cc Rafael for question about ACPI method for PCI host bridge reset] > > On Sat, Nov 14, 2020 at 09:58:08PM +0100, Thomas Gleixner wrote: >> On Sat, Nov 14 2020 at 14:39, Bjorn Helgaas wrote: >> > On Sat, Nov 14, 2020 at 12:40:10AM +0100, Thomas Gleixner wrote: >> >> On Sat, Nov 14 2020 at 00:31, Thomas Gleixner wrote: >> >> > On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote: >> >> >> pci_device_shutdown() still clears the Bus Master Enable bit if we're >> >> >> doing a kexec and the device is in D0-D3hot, which should also disable >> >> >> MSI/MSI-X. Why doesn't this solve the problem? Is this because the >> >> >> device causing the storm was in PCI_UNKNOWN state? >> >> > >> >> > That's indeed a really good question. >> >> >> >> So we do that on kexec, but is that true when starting a kdump kernel >> >> from a kernel crash? I doubt it. >> > >> > Ah, right, I bet that's it, thanks. The kdump path is basically this: >> > >> > crash_kexec >> > machine_kexec >> > >> > while the usual kexec path is: >> > >> > kernel_kexec >> > kernel_restart_prepare >> > device_shutdown >> > while (!list_empty(&devices_kset->list)) >> > dev->bus->shutdown >> > pci_device_shutdown # pci_bus_type.shutdown >> > machine_kexec >> > >> > So maybe we need to explore doing some or all of device_shutdown() in >> > the crash_kexec() path as well as in the kernel_kexec() path. >> >> The problem is that if the machine crashed anything you try to attempt >> before starting the crash kernel is reducing the chance that the crash >> kernel actually starts. > > Right. > >> Is there something at the root bridge level which allows to tell the >> underlying busses to shut up, reset or go into a defined state? That >> might avoid chasing lists which might be already unreliable. > > Maybe we need some kind of crash_device_shutdown() that does the > minimal thing to protect the kdump kernel from devices. The kdump kernel does not use any memory the original kernel uses. Which should be a minimal and fairly robust level of protection until the device drivers can be loaded and get ahold of things. > The programming model for conventional PCI host bridges and PCIe Root > Complexes is device-specific since they're outside the PCI domain. > There probably *are* ways to do those things, but you would need a > native host bridge driver or something like an ACPI method. I'm not > aware of an ACPI way to do this, but I added Rafael in case he is. > > A crash_device_shutdown() could do something at the host bridge level > if that's possible, or reset/disable bus mastering/disable MSI/etc on > individual PCI devices if necessary. Unless I am confused DMA'ing to memory that is not already in use is completely broken wether or not you are using the kdump kernel. Eric _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2020-11-15 14:05 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 [this message] 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 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=87v9e6n2b2.fsf@x220.int.ebiederm.org \ --to=ebiederm@xmission.com \ --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=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=tglx@linutronix.de \ --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.