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 Content-Length: 2043 Lines: 53 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???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?