From: Deepa Dinamani <deepa.kernel@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: Kairui Song <kasong@redhat.com>,
Bjorn Helgaas <helgaas@kernel.org>,
Khalid Aziz <khalid@gonehiking.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-pci@vger.kernel.org, kexec@lists.infradead.org,
Jerry Hoemann <jerry.hoemann@hpe.com>,
Randy Wright <rwright@hpe.com>, Dave Young <dyoung@redhat.com>,
Myron Stowe <myron.stowe@redhat.com>,
jroedel@suse.de
Subject: Re: [RFC PATCH] PCI, kdump: Clear bus master bit upon shutdown in kdump kernel
Date: Wed, 4 Mar 2020 22:06:58 -0800 [thread overview]
Message-ID: <CABeXuvog9KEJQ41Kox8T60fAZ4owip-3bB8XAsndFWF1-udwPQ@mail.gmail.com> (raw)
In-Reply-To: <CABeXuvogFGv8-i4jsJYN5ya0hjf35EXLkmPqYWayDUvXaBKidA@mail.gmail.com>
On Wed, Mar 4, 2020 at 8:53 PM Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>
> On Wed, Mar 4, 2020 at 7:53 PM Baoquan He <bhe@redhat.com> wrote:
> >
> > +Joerg to CC.
> >
> > On 03/03/20 at 01:01pm, Deepa Dinamani wrote:
> > > I looked at this some more. Looks like we do not clear irqs when we do
> > > a kexec reboot. And, the bootup code maintains the same table for the
> > > kexec-ed kernel. I'm looking at the following code in
> >
> > I guess you are talking about kdump reboot here, right? Kexec and kdump
> > boot take the similar mechanism, but differ a little.
>
> Right I meant kdump kernel here. And, clearly the is_kdump_kernel() case below.
>
> >
> > > intel_irq_remapping.c:
> > >
> > > if (ir_pre_enabled(iommu)) {
> > > if (!is_kdump_kernel()) {
> > > pr_warn("IRQ remapping was enabled on %s but
> > > we are not in kdump mode\n",
> > > iommu->name);
> > > clear_ir_pre_enabled(iommu);
> > > iommu_disable_irq_remapping(iommu);
> > > } else if (iommu_load_old_irte(iommu))
> >
> > Here, it's for kdump kernel to copy old ir table from 1st kernel.
>
> Correct.
>
> > > pr_err("Failed to copy IR table for %s from
> > > previous kernel\n",
> > > iommu->name);
> > > else
> > > pr_info("Copied IR table for %s from previous kernel\n",
> > > iommu->name);
> > > }
> > >
> > > Would cleaning the interrupts(like in the non kdump path above) just
> > > before shutdown help here? This should clear the interrupts enabled
> > > for all the devices in the current kernel. So when kdump kernel
> > > starts, it starts clean. This should probably help block out the
> > > interrupts from a device that does not have a driver.
> >
> > I think stopping those devices out of control from continue sending
> > interrupts is a good idea. While not sure if only clearing the interrupt
> > will be enough. Those devices which will be initialized by their driver
> > will brake, but devices which drivers are not loaded into kdump kernel
> > may continue acting. Even though interrupts are cleaning at this time,
> > the on-flight DMA could continue triggerring interrupt since the ir
> > table and iopage table are rebuilt.
>
> This should be handled by the IOMMU, right? And, hence you are getting
> UR. This seems like the correct execution flow to me.
One small correction, I meant the IOMMU and BME here.
next prev parent reply other threads:[~2020-03-05 6:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-25 19:21 [RFC PATCH] PCI, kdump: Clear bus master bit upon shutdown in kdump kernel Kairui Song
2020-01-03 7:58 ` Kairui Song
2020-01-10 21:42 ` Bjorn Helgaas
2020-01-10 22:25 ` Khalid Aziz and Shuah Khan
2020-01-10 23:00 ` Jerry Hoemann
2020-01-11 0:18 ` Khalid Aziz
2020-01-11 0:50 ` Baoquan He
2020-01-11 3:45 ` Khalid Aziz
2020-01-11 9:35 ` Kairui Song
2020-01-11 18:32 ` Deepa Dinamani
2020-01-13 17:07 ` Kairui Song
2020-01-15 1:16 ` Deepa Dinamani
2020-01-15 7:56 ` Kairui Song
2020-01-15 17:30 ` Khalid Aziz
2020-01-15 18:05 ` Kairui Song
2020-01-15 21:17 ` Khalid Aziz
2020-01-17 3:24 ` Dave Young
2020-01-17 3:46 ` Baoquan He
2020-01-17 15:44 ` Khalid Aziz
2020-01-11 10:04 ` Baoquan He
2020-01-11 0:45 ` Baoquan He
2020-01-11 0:51 ` Baoquan He
2020-01-11 1:46 ` Baoquan He
2020-01-11 9:24 ` Kairui Song
2020-01-10 23:36 ` Jerry Hoemann
2020-01-11 8:46 ` Kairui Song
2020-02-22 16:56 ` Bjorn Helgaas
2020-02-24 4:56 ` Dave Young
2020-02-24 17:30 ` Kairui Song
2020-02-28 19:53 ` Deepa Dinamani
2020-03-03 21:01 ` Deepa Dinamani
2020-03-05 3:53 ` Baoquan He
2020-03-05 4:53 ` Deepa Dinamani
2020-03-05 6:06 ` Deepa Dinamani [this message]
2020-03-06 9:38 ` Baoquan He
2020-07-22 14:52 ` Kairui Song
2020-07-22 15:21 ` Bjorn Helgaas
2020-07-22 21:50 ` Jerry Hoemann
2020-07-23 0:00 ` Bjorn Helgaas
2020-07-23 18:34 ` Kairui Song
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=CABeXuvog9KEJQ41Kox8T60fAZ4owip-3bB8XAsndFWF1-udwPQ@mail.gmail.com \
--to=deepa.kernel@gmail.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=helgaas@kernel.org \
--cc=jerry.hoemann@hpe.com \
--cc=jroedel@suse.de \
--cc=kasong@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=khalid@gonehiking.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=myron.stowe@redhat.com \
--cc=rwright@hpe.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).