From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753061AbbDCOGq (ORCPT ); Fri, 3 Apr 2015 10:06:46 -0400 Received: from g4t3426.houston.hp.com ([15.201.208.54]:45745 "EHLO g4t3426.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751953AbbDCOGp (ORCPT ); Fri, 3 Apr 2015 10:06:45 -0400 From: "Li, Zhen-Hua" To: Dave Young CC: "dwmw2@infradead.org" , "indou.takao@jp.fujitsu.com" , "bhe@redhat.com" , "joro@8bytes.org" , "vgoyal@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" , "Hatch, Douglas B (HPS Linux PM)" , "Hoemann, Jerry" , "Vaden, Tom (HP Server OS Architecture)" , "Zhang, Li (Zoe@HPservers-Core-OE-PSC)" , "Mitchell, Lisa (MCLinux in Fort Collins)" , "billsumnerlinux@gmail.com" , "Wright, Randy (HP Servers Linux)" Subject: Re: [PATCH v9 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel Thread-Topic: [PATCH v9 0/10] iommu/vt-d: Fix intel vt-d faults in kdump kernel Thread-Index: AQHQYga6VYnLAyC/gUm4Hu8qw/LRCp07D6KAgAAF6wCAAAVxgIAAT3hl Date: Fri, 3 Apr 2015 14:05:36 +0000 Message-ID: <534F7596-2172-4BE1-B374-4D18D2DA5110@hp.com> References: <1426743388-26908-1-git-send-email-zhen-hual@hp.com> <20150403084031.GF22579@dhcp-128-53.nay.redhat.com> <551E56F6.60503@hp.com>,<20150403092111.GG22579@dhcp-128-53.nay.redhat.com> In-Reply-To: <20150403092111.GG22579@dhcp-128-53.nay.redhat.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t33E6qaA016720 The hardware will do some verification, but not completely. If people think the OS should also do this, then it should be another patchset, I think. Thanks Zhenhua > 在 2015年4月3日，17:21，Dave Young 写道： > >> On 04/03/15 at 05:01pm, Li, ZhenHua wrote: >> Hi Dave, >> >> There may be some possibilities that the old iommu data is corrupted by >> some other modules. Currently we do not have a better solution for the >> dmar faults. >> >> But I think when this happens, we need to fix the module that corrupted >> the old iommu data. I once met a similar problem in normal kernel, the >> queue used by the qi_* functions was written again by another module. >> The fix was in that module, not in iommu module. > > It is too late, there will be no chance to save vmcore then. > > Also if it is possible to continue corrupt other area of oldmem because > of using old iommu tables then it will cause more problems. > > So I think the tables at least need some verifycation before being used. > >> >> >> Thanks >> Zhenhua >> >> On 04/03/2015 04:40 PM, Dave Young wrote: >>>> 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. >>> >>> Have not read all the patches, but I have a question, not sure this has been >>> answered before. Old memory is not reliable, what if the old memory get corrupted >>> before panic? Is it safe to continue using it in 2nd kernel, I worry that it will >>> cause problems. >>> >>> Hope I'm wrong though. >>> >>> Thanks >>> Dave >> 翳簕.n+壏煯壄+%娝遍荻w簕.n+壏{炳G珴妠ay蕠跈,jf＂穐殢飦戧鐉_璁(殠娸"濟mG珴⒏?櫒璀&ｘ忈秈O曟瑉窔v豝m 鹅⒏?朓