Message-ID: <5552AEE9.80408@hp.com>
Date:	Wed, 13 May 2015 09:54:49 +0800
From:	"Li, ZhenHua" <zhen-hual@...com>
To:	joro@...tes.org, linux-pci@...r.kernel.org,
	kexec@...ts.infradead.org, bhelgaas@...gle.com
CC:	"Li, Zhen-Hua" <zhen-hual@...com>, dwmw2@...radead.org,
	indou.takao@...fujitsu.com, bhe@...hat.com, vgoyal@...hat.com,
	dyoung@...hat.com, iommu@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, alex.williamson@...hat.com,
	ddutile@...hat.com, ishii.hironobu@...fujitsu.com,
	doug.hatch@...com, jerry.hoemann@...com, tom.vaden@...com,
	li.zhang6@...com, lisa.mitchell@...com, billsumnerlinux@...il.com,
	rwright@...com
Subject: Re: [PATCH v11 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel

One thing must be pointed out:
There is a known issue that hpsa driver cannot work well in kdump 
kernel. And this patchset is not intended to fix this problem.

So this patchset cannot work with HP smart array devices which need hpsa 
driver.

On 05/11/2015 05:52 PM, Li, Zhen-Hua wrote:
> This patchset is an update of Bill Sumner's patchset, implements a fix for:
> If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
> when a panic happens, the kdump kernel will boot with these faults:
>
>      dmar: DRHD: handling fault status reg 102
>      dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr fff80000
>      DMAR:[fault reason 01] Present bit in root entry is clear
>
>      dmar: DRHD: handling fault status reg 2
>      dmar: INTR-REMAP: Request device [[61:00.0] fault index 42
>      INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear
>
> On some system, the interrupt remapping fault will also happen even if the
> intel_iommu is not set to on, because the interrupt remapping will be enabled
> when x2apic is needed by the system.
>
> The cause of the DMA fault is described in Bill's original version, and the
> INTR-Remap fault is caused by a similar reason. In short, the initialization
> of vt-d drivers causes the in-flight DMA and interrupt requests get wrong
> response.
>
> To fix this problem, we modifies the behaviors of the intel vt-d in the
> crashdump kernel:
>
> For DMA Remapping:
> 1. To accept the vt-d hardware in an active state,
> 2. Do not disable and re-enable the translation, keep it enabled.
> 3. Use the old root entry table, do not rewrite the RTA register.
> 4. Malloc and use new context entry table, copy data from the old ones that
>     used by the old kernel.
> 5. Keep using the old page tables before driver is loaded.
> 6. After device driver is loaded, when it issues the first dma_map command,
>     free the dmar_domain structure for this device, and generate a new one, so
>     that the device can be assigned a new and empty page table.
> 7. When a new context entry table is generated, we also save its address to
>     the old root entry table.
>
> For Interrupt Remapping:
> 1. To accept the vt-d hardware in an active state,
> 2. Do not disable and re-enable the interrupt remapping, keep it enabled.
> 3. Use the old interrupt remapping table, do not rewrite the IRTA register.
> 4. When ioapic entry is setup, the interrupt remapping table is changed, and
>     the updated data will be stored to the old interrupt remapping table.
>
> 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 vt-d code.
>
> Summary of changes in this patch set:
> 1. Added some useful function for root entry table in code intel-iommu.c
> 2. Added new members to struct root_entry and struct irte;
> 3. Functions to load old root entry table to iommu->root_entry from the memory
>     of old kernel.
> 4. Functions to malloc new context entry table and copy the data from the old
>     ones to the malloced new ones.
> 5. Functions to enable support for DMA remapping in kdump kernel.
> 6. Functions to load old irte data from the old kernel to the kdump kernel.
> 7. Some code changes that support other behaviours that have been listed.
> 8. In the new functions, use physical address as "unsigned long" type, not
>     pointers.
>
> Original version by Bill Sumner:
>      https://lkml.org/lkml/2014/1/10/518
>      https://lkml.org/lkml/2014/4/15/716
>      https://lkml.org/lkml/2014/4/24/836
>
> Zhenhua's updates:
>      https://lkml.org/lkml/2014/10/21/134
>      https://lkml.org/lkml/2014/12/15/121
>      https://lkml.org/lkml/2014/12/22/53
>      https://lkml.org/lkml/2015/1/6/1166
>      https://lkml.org/lkml/2015/1/12/35
>      https://lkml.org/lkml/2015/3/19/33
>      https://lkml.org/lkml/2015/4/10/135
>
> Changelog[v11]:
>      1. Fix some conflicts with the latest upstream kernel.
>         Add flush in iommu_context_addr
>
> Changelog[v10]:
>      1. Do not use CONFIG_CRASH_DUMP and is_kdump_kernel().
>         Use one flag which stores the te and ir status in last kernel:
>             iommu->pre_enabled_trans
>             iommu->pre_enabled_ir
>
> Changelog[v9]:
>      1. Add new function iommu_attach_domain_with_id.
>      2. Do not copy old page tables, keep using the old ones.
>      3. Remove functions:
>             intel_iommu_did_to_domain_values_entry
>             intel_iommu_get_dids_from_old_kernel
>             device_to_domain_id
>             copy_page_addr
>             copy_page_table
>             copy_context_entry
>             copy_context_entry_table
>      4. Add new function device_to_existing_context_entry.
>
> Changelog[v8]:
>      1. Add a missing __iommu_flush_cache in function copy_page_table.
>
> Changelog[v7]:
>      1. Use __iommu_flush_cache to flush the data to hardware.
>
> Changelog[v6]:
>      1. Use "unsigned long" as type of physical address.
>      2. Use new function unmap_device_dma to unmap the old dma.
>      3. Some small incorrect bits order for aw shift.
>
> Changelog[v5]:
>      1. Do not disable and re-enable traslation and interrupt remapping.
>      2. Use old root entry table.
>      3. Use old interrupt remapping table.
>      4. New functions to copy data from old kernel, and save to old kernel mem.
>      5. New functions to save updated root entry table and irte table.
>      6. Use intel_unmap to unmap the old dma;
>      7. Allocate new pages while driver is being loaded.
>
> Changelog[v4]:
>      1. Cut off the patches that move some defines and functions to new files.
>      2. Reduce the numbers of patches to five, make it more easier to read.
>      3. Changed the name of functions, make them consistent with current context
>         get/set functions.
>      4. Add change to function __iommu_attach_domain.
>
> Changelog[v3]:
>      1. Commented-out "#define DEBUG 1" to eliminate debug messages.
>      2. Updated the comments about changes in each version.
>      3. Fixed: one-line added to Copy-Translations patch to initialize the iovad
>            struct as recommended by Baoquan He [bhe@...hat.com]
>            init_iova_domain(&domain->iovad, DMA_32BIT_PFN);
>
> Changelog[v2]:
>      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 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.
>
> Changelog[v1]:
>      The original version.
>
> Changed in this version:
> 1. Do not disable and re-enable traslation and interrupt remapping.
> 2. Use old root entry table.
> 3. Use old interrupt remapping table.
> 4. Use "unsigned long" as physical address.
> 5. Use intel_unmap to unmap the old dma;
>
> Baoquan He <bhe@...hat.com> helps testing this patchset.
> Takao Indoh <indou.takao@...fujitsu.com> gives valuable suggestions.
>
> Li, Zhen-Hua (10):
>    iommu/vt-d: New function to attach domain with id
>    iommu/vt-d: Items required for kdump
>    iommu/vt-d: Function to get existing context entry
>    iommu/vt-d: functions to copy data from old mem
>    iommu/vt-d: Add functions to load and save old re
>    iommu/vt-d: datatypes and functions used for kdump
>    iommu/vt-d: enable kdump support in iommu module
>    iommu/vt-d: assign new page table for dma_map
>    iommu/vt-d: Copy functions for irte
>    iommu/vt-d: Use old irte in kdump kernel
>
>   drivers/iommu/intel-iommu.c         | 536 ++++++++++++++++++++++++++++++++++--
>   drivers/iommu/intel_irq_remapping.c |  96 ++++++-
>   include/linux/intel-iommu.h         |  16 ++
>   3 files changed, 623 insertions(+), 25 deletions(-)
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists