From patchwork Mon Dec 29 03:15:45 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Li, Zhen-Hua" X-Patchwork-Id: 5547831 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id BB6B4BF6C3 for ; Mon, 29 Dec 2014 03:17:04 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3813B20117 for ; Mon, 29 Dec 2014 03:17:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A76762010E for ; Mon, 29 Dec 2014 03:17:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751765AbaL2DQs (ORCPT ); Sun, 28 Dec 2014 22:16:48 -0500 Received: from g4t3427.houston.hp.com ([15.201.208.55]:59139 "EHLO g4t3427.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751683AbaL2DQr (ORCPT ); Sun, 28 Dec 2014 22:16:47 -0500 Received: from g9t2301.houston.hp.com (g9t2301.houston.hp.com [16.216.185.78]) by g4t3427.houston.hp.com (Postfix) with ESMTP id 95BE86E; Mon, 29 Dec 2014 03:16:46 +0000 (UTC) Received: from [16.187.245.3] (piepie.asiapacific.hpqcorp.net [16.187.245.3]) by g9t2301.houston.hp.com (Postfix) with ESMTP id EEA9367; Mon, 29 Dec 2014 03:16:40 +0000 (UTC) Message-ID: <54A0C761.5060604@hp.com> Date: Mon, 29 Dec 2014 11:15:45 +0800 From: "Li, ZhenHua" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Takao Indoh CC: dwmw2@infradead.org, bhe@redhat.com, joro@8bytes.org, vgoyal@redhat.com, dyoung@redhat.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, kexec@lists.infradead.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, billsumnerlinux@gmail.com Subject: Re: [PATCH 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel References: <1419239729-26529-1-git-send-email-zhen-hual@hp.com> <549CEE8F.2090209@jp.fujitsu.com> <549D0459.4080202@hp.com> <549D0DEE.8000301@jp.fujitsu.com> In-Reply-To: <549D0DEE.8000301@jp.fujitsu.com> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Takao Indoh, Happy New Year, and thank you very much for you help. The flush is quite a problem, as there are several places the flush function should be called, I think the flush should be placed in functions like __iommu_update_old_*. Created a small patch for this, it is attached. As I cannot reproduce your problems on my system, so could you please try these steps? 1. Apply the latest patchset, including 9/10 and 10/10, and then apply the attached patch_for_flush.patch. And then test the kernel. 2. If 1 does not fix the DMAR fault problems, then it might be caused by 7/10, so please *unpatch* it from the kernel (others and the attached one should be patched), and then test the kernel. Regards Zhenhua On 12/26/2014 03:27 PM, Takao Indoh wrote: > On 2014/12/26 15:46, Li, ZhenHua wrote: >> Hi Takao Indoh, >> >> Thank you very much for your testing. I will add your update in next >> version. >> Also I think a flush for __iommu_update_old_root_entry is also necessary. >> >> Currently I have no idea about your fault, does it happen before or >> during its loading? Could you send me your full kernel log as an >> attachment? > Sure, see attached file. > > I removed 9/10 and 10/10 patches from my kernel to avoid panic problem I > reported in previous mail, and then tested kdump. So please ignore > intr-remap fault message in log file. Also please ignore stack trace > starting with the following message, it's a problem of my box. > > Flags mismatch irq 0. 00000080 (i801_smbus) vs. 00015a00 (timer) > > Thanks, > Takao Indoh > >> Regards and Merry Christmas. >> Zhenhua >> >> On 12/26/2014 01:13 PM, Takao Indoh wrote: >>> Hi Zhen-Hua, >>> >>> I tested your patch and found two problems. >>> >>> [1] >>> Kenel panic occurs during 2nd kernel boot. >>> >>> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 >>> Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APIC >>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0 #25 >>> Hardware name: FUJITSU-SV PRIMERGY BX920 S2/D3030, BIOS 080015 Rev.3D81.3030 02/10/2012 >>> 0000000000000002 ffff880036167d08 ffffffff815b1c6a 0000000000000000 >>> ffffffff817f7670 ffff880036167d88 ffffffff815b19f1 0000000000000008 >>> ffff880036167d98 ffff880036167d38 ffffffff810a5d2f ffff880036167d98 >>> Call Trace: >>> [] dump_stack+0x48/0x5e >>> [] panic+0xbb/0x1fa >>> [] ? vprintk_default+0x1f/0x30 >>> [] panic_if_irq_remap+0x1c/0x20 >>> [] check_timer+0x1e7/0x5ed >>> [] ? radix_tree_lookup+0xd/0x10 >>> [] setup_IO_APIC+0x261/0x292 >>> [] native_smp_prepare_cpus+0x214/0x25d >>> [] kernel_init_freeable+0x1dc/0x28c >>> [] ? rest_init+0x80/0x80 >>> [] kernel_init+0xe/0xf0 >>> [] ret_from_fork+0x7c/0xb0 >>> [] ? rest_init+0x80/0x80 >>> ---[ end Kernel panic - not syncing: timer doesn't work through Interrupt-remapped IO-APIC >>> >>> >>> This panic seems to be related to unflushed cache. I confirmed this >>> problem was fixed by the following patch. >>> >>> --- a/drivers/iommu/intel_irq_remapping.c >>> +++ b/drivers/iommu/intel_irq_remapping.c >>> @@ -200,8 +200,13 @@ static int modify_irte(int irq, struct irte *irte_modified) >>> set_64bit(&irte->high, irte_modified->high); >>> >>> #ifdef CONFIG_CRASH_DUMP >>> - if (is_kdump_kernel()) >>> + if (is_kdump_kernel()) { >>> __iommu_update_old_irte(iommu, index); >>> + __iommu_flush_cache(iommu, >>> + iommu->ir_table->base_old_virt + >>> + index * sizeof(struct irte), >>> + sizeof(struct irte)); >>> + } >>> #endif >>> __iommu_flush_cache(iommu, irte, sizeof(*irte)); >>> >>> >>> [2] >>> Some DMAR error messages are still found in 2nd kernel boot. >>> >>> dmar: DRHD: handling fault status reg 2 >>> dmar: DMAR:[DMA Write] Request device [01:00.0] fault addr ffded000 >>> DMAR:[fault reason 01] Present bit in root entry is clear >>> >>> I confiremd your commit 1a2262 was already applied. Any idea? >>> >>> Thanks, >>> Takao Indoh >>> >>> >>> On 2014/12/22 18:15, 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 and page table, copy data from the >>>> old ones that used by the old kernel. >>>> 5. 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. >>>> 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 page 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 last of Bill's patchset: >>>> https://lkml.org/lkml/2014/10/21/134 >>>> https://lkml.org/lkml/2014/12/15/121 >>>> >>>> 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; >>>> >>>> This patchset should be applied with this one together: >>>> https://lkml.org/lkml/2014/11/5/43 >>>> x86/iommu: fix incorrect bit operations in setting values >>>> >>>> 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 >>>> >>>> Li, Zhen-Hua (10): >>>> iommu/vt-d: Update iommu_attach_domain() and its callers >>>> iommu/vt-d: Items required for kdump >>>> iommu/vt-d: Add domain-id functions >>>> 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/vtd: 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 | 1050 +++++++++++++++++++++++++++++++++-- >>>> drivers/iommu/intel_irq_remapping.c | 99 +++- >>>> include/linux/intel-iommu.h | 18 + >>>> 3 files changed, 1123 insertions(+), 44 deletions(-) >>>> >> >> diff -urp a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c --- a/drivers/iommu/intel-iommu.c 2014-12-29 10:52:02.000000000 +0800 +++ b/drivers/iommu/intel-iommu.c 2014-12-29 09:36:23.000000000 +0800 @@ -5188,6 +5188,8 @@ static void __iommu_load_old_root_entry( || (!iommu->root_entry_old_phys)) return; memcpy(iommu->root_entry, iommu->root_entry_old_virt, PAGE_SIZE); + + __iommu_flush_cache(iommu, iommu->root_entry, PAGE_SIZE); } /* @@ -5220,6 +5222,8 @@ static void __iommu_update_old_root_entr to = iommu->root_entry_old_virt; from = iommu->root_entry; memcpy(to + start, from + start, size); + + __iommu_flush_cache(iommu, to + start, size); } /* diff -urp a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c --- a/drivers/iommu/intel_irq_remapping.c 2014-12-29 10:52:02.000000000 +0800 +++ b/drivers/iommu/intel_irq_remapping.c 2014-12-29 09:51:52.000000000 +0800 @@ -1350,6 +1350,9 @@ static int __iommu_load_old_irte(struct iommu->ir_table->base_old_virt, INTR_REMAP_TABLE_ENTRIES*sizeof(struct irte)); + __iommu_flush_cache(iommu, iommu->ir_table->base, + INTR_REMAP_TABLE_ENTRIES*sizeof(struct irte)); + return 0; } @@ -1382,6 +1385,8 @@ static int __iommu_update_old_irte(struc from = iommu->ir_table->base; memcpy(to + start, from + start, size); + __iommu_flush_cache(iommu, to + start, size); + return 0; } #endif /* CONFIG_CRASH_DUMP */