From: Neil Horman <nhorman@tuxdriver.com>
To: Chris Wright <chrisw@sous-sol.org>
Cc: iommu@lists.linux-foundation.org, joerg.roedel@amd.com,
vgoyal@redhat.com, hbabu@us.ibm.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] amd iommu: force flush of iommu prior during shutdown
Date: Wed, 31 Mar 2010 21:13:11 -0400 [thread overview]
Message-ID: <20100401011311.GC2069@localhost.localdomain> (raw)
In-Reply-To: <20100331212535.GR29241@sequoia.sous-sol.org>
On Wed, Mar 31, 2010 at 02:25:35PM -0700, Chris Wright wrote:
> * Neil Horman (nhorman@tuxdriver.com) wrote:
> > Flush iommu during shutdown
> >
> > When using an iommu, its possible, if a kdump kernel boot follows a primary
> > kernel crash, that dma operations might still be in flight from the previous
> > kernel during the kdump kernel boot. This can lead to memory corruption,
> > crashes, and other erroneous behavior, specifically I've seen it manifest during
> > a kdump boot as endless iommu error log entries of the form:
> > AMD-Vi: Event logged [IO_PAGE_FAULT device=00:14.1 domain=0x000d
> > address=0x000000000245a0c0 flags=0x0070]
>
> We've already fixed this problem once before, so some code shift must
> have brought it back. Personally, I prefer to do this on the bringup
> path than the teardown path. Besides keeping the teardown path as
> simple as possible (goal is to get to kdump kernel asap), there's also
> reason to competely flush on startup in genernal in case BIOS has done
> anything unsavory.
>
Chris,
Can you elaborate on what you did with the iommu to make this safe? It
will save me time digging through the history on this code, and help me
understand better whats going on here.
I was starting to think that we should just leave the iommu on through a kdump,
and re-construct a new page table based on the old table (filtered by the error
log) on kdump boot, but it sounds like a better solution might be in place.
Thanks
Neil
> thanks,
> -chris
>
next prev parent reply other threads:[~2010-04-01 1:13 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-31 15:24 [PATCH] amd iommu: force flush of iommu prior during shutdown Neil Horman
2010-03-31 15:54 ` Vivek Goyal
2010-03-31 18:28 ` Neil Horman
2010-03-31 18:57 ` Eric W. Biederman
2010-03-31 19:18 ` Neil Horman
2010-03-31 19:51 ` Eric W. Biederman
2010-03-31 20:27 ` Neil Horman
2010-04-01 4:04 ` Eric W. Biederman
2010-04-01 12:49 ` Neil Horman
2010-04-01 14:29 ` Joerg Roedel
2010-04-01 14:47 ` Neil Horman
2010-04-01 15:56 ` Joerg Roedel
2010-04-01 17:11 ` Neil Horman
2010-04-01 20:14 ` Joerg Roedel
2010-04-02 0:00 ` Neil Horman
2010-04-02 0:30 ` Chris Wright
2010-04-02 1:23 ` [PATCH 1/2] x86/amd-iommu: enable iommu before attaching devices Chris Wright
2010-04-02 1:31 ` [PATCH 2/2] x86/amd-iommu: warn when issuing command to uninitiailed cmd buffer Chris Wright
2010-04-02 1:35 ` [PATCH 1/2] x86/amd-iommu: enable iommu before attaching devices Neil Horman
2010-04-02 1:38 ` Chris Wright
2010-04-02 9:11 ` Joerg Roedel
2010-04-02 23:59 ` Chris Wright
2010-04-02 15:59 ` Vivek Goyal
2010-04-02 22:38 ` Chris Wright
2010-04-02 22:55 ` Eric W. Biederman
2010-04-02 23:57 ` Chris Wright
2010-04-03 17:38 ` Joerg Roedel
2010-04-05 14:17 ` Vivek Goyal
2010-04-05 14:32 ` Joerg Roedel
2010-04-05 15:34 ` Neil Horman
2010-03-31 18:43 ` [PATCH] amd iommu: force flush of iommu prior during shutdown Eric W. Biederman
2010-03-31 21:25 ` Chris Wright
2010-04-01 1:13 ` Neil Horman [this message]
2010-04-01 1:39 ` Chris Wright
2010-04-01 2:24 ` Vivek Goyal
2010-04-01 12:53 ` Neil Horman
2010-04-01 15:02 ` Vivek Goyal
2010-04-01 15:13 ` Neil Horman
2010-04-01 2:44 ` Vivek Goyal
2010-04-01 7:10 ` Chris Wright
2010-04-01 12:56 ` Neil Horman
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=20100401011311.GC2069@localhost.localdomain \
--to=nhorman@tuxdriver.com \
--cc=chrisw@sous-sol.org \
--cc=hbabu@us.ibm.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joerg.roedel@amd.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.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