From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Khalid Aziz <khalid.aziz@oracle.com>,
Chang Liu <cl91tp@gmail.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Lan Tianyu <tianyu.lan@intel.com>,
Konstantin Khlebnikov <khlebnikov@openvz.org>,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Takao Indoh <indou.takao@jp.fujitsu.com>,
Jility <jility09@gmail.com>, Florian Otti <f.otti@gmx.at>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] PCI: add a quirk for keeping Bus Master bit on shutdown
Date: Tue, 26 Nov 2013 17:48:06 +0000 [thread overview]
Message-ID: <20131126174806.GA14789@srcf.ucam.org> (raw)
In-Reply-To: <CAErSpo6eAbVDfc8PFPP4b4HLzAjkFe23pJytu-TZq-V8-pfQMA@mail.gmail.com>
On Tue, Nov 26, 2013 at 10:35:26AM -0700, Bjorn Helgaas wrote:
> On Tue, Nov 26, 2013 at 9:40 AM, Khalid Aziz <khalid.aziz@oracle.com> wrote:
> > Disabling Bus Master bit is effectively a brute force and not an elegant way
> > to stop unwanted DMA. It can have side effects as Alan and others pointed
> > out in the original discussion, and we are now seeing one with Lynx Point on
> > Acer.
>
> I'm getting more queasy all the time about disabling Bus Master. I
> don't think RHEL does it, and that's probably where most kexec use is.
> So I doubt we really have much experience with it yet.
Does Windows disable the BM bit on shutdown? If not, it's likely that
there are platforms where the SMM code assumes it's still enabled. We
also know that there are devices that hang if BM is disabled while their
DMA engines are still running.
Unless we verify that Windows does this, I think there's no way we can
guarantee that firmware won't make assumptions about the state of PCI.
The easiest compromise would probably be to set a flag that disables
busmastering purely when we're performing a kexec.
> > Eric had pointed out in original discussion -
> > <http://marc.info/?l=linux-pci&m=133901193430829&w=2> that this code change
> > moves failure from a random point in the kexec'd kernel to a predictable
> > point on shutdown path where it becomes lot easier to debug than a random
> > memory overwrite.
>
> That is probably true in some cases, but not this one. I have no idea
> how to debug this poweroff hang. Poweroff is a path *everybody* uses,
> so it's much more important to have that work reliably than it is to
> have kexec work.
If it's hanging after we've performed the io writes that trap us into
SMM, there's no meaningful way for us to debug it. We're violating
assumptions that the firmware is making, and the only way to fix that is
to cease violating those assumptions.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2013-11-26 17:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 19:40 [PATCH] PCI: add a quirk for keeping Bus Master bit on shutdown Chang Liu
2013-11-26 3:33 ` Bjorn Helgaas
2013-11-26 4:11 ` Chang Liu
2013-11-26 4:20 ` Bjorn Helgaas
2013-11-26 5:39 ` Lan Tianyu
2013-11-26 16:40 ` Khalid Aziz
2013-11-26 17:35 ` Bjorn Helgaas
2013-11-26 17:48 ` Matthew Garrett [this message]
2013-11-26 18:37 ` Khalid Aziz
2013-11-26 19:38 ` Konstantin Khlebnikov
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=20131126174806.GA14789@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=bhelgaas@google.com \
--cc=cl91tp@gmail.com \
--cc=ebiederm@xmission.com \
--cc=f.otti@gmx.at \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=indou.takao@jp.fujitsu.com \
--cc=jility09@gmail.com \
--cc=khalid.aziz@oracle.com \
--cc=khlebnikov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=tianyu.lan@intel.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).