From: "Li, Zhen-Hua" <zhen-hual@hp.com>
To: <dwmw2@infradead.org>, <indou.takao@jp.fujitsu.com>,
<bhe@redhat.com>, <joro@8bytes.org>, <vgoyal@redhat.com>,
<dyoung@redhat.com>
Cc: <iommu@lists.linux-foundation.org>, <kexec@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <linux-pci@vger.kernel.org>,
<alex.williamson@redhat.com>, <ddutile@redhat.com>,
<ishii.hironobu@jp.fujitsu.com>, <bhelgaas@google.com>,
<doug.hatch@hp.com>, <jerry.hoemann@hp.com>, <tom.vaden@hp.com>,
<li.zhang6@hp.com>, <lisa.mitchell@hp.com>,
"Li, Zhen-Hua" <zhen-hual@hp.com>
Subject: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Date: Tue, 21 Oct 2014 16:04:14 +0800 [thread overview]
Message-ID: <1413878659-1383-1-git-send-email-zhen-hual@hp.com> (raw)
The following series implements a fix for:
A kdump problem about DMA that has been discussed for a long time.
That is, when a kernel panics and boots into the kdump kernel, DMA that was
started by the panicked kernel is not stopped before the kdump kernel is booted;
and the kdump kernel disables the IOMMU while this DMA continues.
This causes the IOMMU to stop translating the DMA addresses as IOVAs and
begin to treat them as physical memory addresses -- which causes the DMA to either:
1. generate DMAR errors or
2. generate PCI SERR errors or
3. transfer data to or from incorrect areas of memory.
Often this causes the dump to fail.
This patch set modifies the behavior of the Intel iommu in the crashdump kernel:
1. to accept the iommu hardware in an active state,
2. to leave the current translations in-place so that legacy DMA will continue
using its current buffers until the device drivers in the crashdump kernel
initialize and initialize their devices,
3. to use different portions of the iova address ranges for the device drivers
in the crashdump kernel than the iova ranges that were in-use at the time
of the panic.
Advantages of this approach:
1. All manipulation of the IO-device is done by the Linux device-driver
for that device.
2. This approach behaves in a manner very similar to operation without an
active iommu.
3. Any activity between the IO-device and its RMRR areas is handled by the
device-driver in the same manner as during a non-kdump boot.
4. If an IO-device has no driver in the kdump kernel, it is simply left alone.
This supports the practice of creating a special kdump kernel without
drivers for any devices that are not required for taking a crashdump.
5. Minimal code-changes among the existing mainline intel-iommu code.
Summary of changes in this patch set:
1. Updated to a more current top-of-tree and merged the code with the
large number of changes that were recently taken-in to intel-iommu.c
2. Returned to the structure of a patch-set
3. Enabled the intel-iommu driver to consist of multiple *.c files
by moving many of the #defines, prototypes, and inline functions
into a new file: intel-iommu-private.h (First three patches implement
only this enhancement -- could be applied independent of the last 5)
4. Moved the new "crashdump fix" code into a new file: intel-iommu-kdump.c
5. Removed the pr_debug constructs from the new code that implements the
"crashdump fix" -- making the code much cleaner and easier to read.
6. Miscellaneous cleanups such as enum-values for return-codes.
7. Simplified the code that retrieves the values needed to initialize a new
domain by using the linked-list of previously-collected values
instead of stepping back into the tree of translation tables.
Original version by Bill Sumner:
https://lkml.org/lkml/2014/4/24/836
Changed in this version:
Split the original patchset into two sets. This patchset includes
4~8 patches in the original set.
Bill Sumner (5):
iommu/vt-d: Update iommu_attach_domain() and its callers
iommu/vt-d: Items required for kdump
iommu/vt-d: data types and functions used for kdump
iommu/vt-d: Add domain-id functions
iommu/vt-d: enable kdump support in iommu module
drivers/iommu/intel-iommu.c | 829 ++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 803 insertions(+), 26 deletions(-)
--
2.0.0-rc0
next reply other threads:[~2014-10-21 8:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 8:04 Li, Zhen-Hua [this message]
2014-10-21 8:04 ` [PATCH 1/5] iommu/vt-d: Update iommu_attach_domain() and its callers Li, Zhen-Hua
2014-10-21 8:04 ` [PATCH 2/5] iommu/vt-d: Items required for kdump Li, Zhen-Hua
2014-10-21 8:04 ` [PATCH 3/5] iommu/vt-d: data types and functions used " Li, Zhen-Hua
2014-10-21 8:04 ` [PATCH 4/5] iommu/vt-d: Add domain-id functions Li, Zhen-Hua
2014-10-21 8:04 ` [PATCH 5/5] iommu/vt-d: enable kdump support in iommu module Li, Zhen-Hua
2014-10-22 10:05 ` [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO Baoquan He
2014-10-22 10:22 ` Li, Zhen-Hua
2014-10-22 10:27 ` Baoquan He
2014-10-27 7:29 ` Li, ZhenHua
2014-10-27 10:44 ` Baoquan He
2014-11-06 1:31 ` Takao Indoh
2014-11-06 1:35 ` Li, ZhenHua
2014-11-06 1:48 ` Takao Indoh
2014-11-06 2:11 ` Li, ZhenHua
2014-11-06 7:51 ` Takao Indoh
2014-11-06 8:06 ` Li, ZhenHua
2014-11-14 6:27 ` Li, ZhenHua
2014-11-17 13:38 ` Joerg Roedel
2014-12-01 6:31 ` Li, ZhenHua
2014-12-01 12:33 ` Joerg Roedel
2014-12-10 8:46 ` Baoquan He
2014-12-12 2:25 ` Li, ZhenHua
2014-12-12 16:11 ` Joerg Roedel
2014-12-15 9:13 ` Baoquan He
2014-12-15 9:16 ` Baoquan He
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=1413878659-1383-1-git-send-email-zhen-hual@hp.com \
--to=zhen-hual@hp.com \
--cc=alex.williamson@redhat.com \
--cc=bhe@redhat.com \
--cc=bhelgaas@google.com \
--cc=ddutile@redhat.com \
--cc=doug.hatch@hp.com \
--cc=dwmw2@infradead.org \
--cc=dyoung@redhat.com \
--cc=indou.takao@jp.fujitsu.com \
--cc=iommu@lists.linux-foundation.org \
--cc=ishii.hironobu@jp.fujitsu.com \
--cc=jerry.hoemann@hp.com \
--cc=joro@8bytes.org \
--cc=kexec@lists.infradead.org \
--cc=li.zhang6@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lisa.mitchell@hp.com \
--cc=tom.vaden@hp.com \
--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;
as well as URLs for NNTP newsgroup(s).