From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXb0D-0006LT-TM for kexec@lists.infradead.org; Tue, 08 Apr 2014 18:44:10 +0000 Message-ID: <53444330.2030606@redhat.com> Date: Tue, 08 Apr 2014 14:42:56 -0400 From: Don Dutile MIME-Version: 1.0 Subject: Re: [PATCHv3 0/6] Crashdump Accepting Active IOMMU References: <1389391652-52422-1-git-send-email-bill.sumner@hp.com> <53430DE9.9080303@redhat.com> <1396973686.25235.36.camel@i7.infradead.org> In-Reply-To: <1396973686.25235.36.camel@i7.infradead.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: David Woodhouse Cc: indou.takao@jp.fujitsu.com, bhe@redhat.com, linux-pci@vger.kernel.org, joro@8bytes.org, kexec@lists.infradead.org, alex.williamson@redhat.com, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, doug.hatch@hp.com, ishii.hironobu@jp.fujitsu.com, bhelgaas@google.com, zhenhua@hp.com, Bill Sumner On 04/08/2014 12:14 PM, David Woodhouse wrote: > On Mon, 2014-04-07 at 16:43 -0400, Don Dutile wrote: >> >> Additionally, a tidbit of information like "some servers force NMI's >> on DMAR faults, >> and cause a system reset, thereby, preventing a kdump to occur" >> should have been included as one reason to stop DMAR faults from >> occurring on kexec-boot, >> in addition to the fact that a flood of them can lock up a system. > > How about allocating a physical scratch page, and setting up a mapping > for each device such that *every* virtual address (apart from those > listed in RMRRs, perhaps) is mapped to that same scratch page? > > That way you avoid the faults, but you also avoid stray DMA to parts of > the system that you don't want to get corrupted. > +1... more isolation as second kernel booting sounds good. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Dutile Subject: Re: [PATCHv3 0/6] Crashdump Accepting Active IOMMU Date: Tue, 08 Apr 2014 14:42:56 -0400 Message-ID: <53444330.2030606@redhat.com> References: <1389391652-52422-1-git-send-email-bill.sumner@hp.com> <53430DE9.9080303@redhat.com> <1396973686.25235.36.camel@i7.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1396973686.25235.36.camel-W2I5cNIroUsVm/YvaOjsyQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: David Woodhouse Cc: bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, doug.hatch-VXdhtT5mjnY@public.gmane.org, ishii.hironobu-+CUm20s59erQFUHtdCDX3A@public.gmane.org, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, zhenhua-VXdhtT5mjnY@public.gmane.org, Bill Sumner List-Id: iommu@lists.linux-foundation.org On 04/08/2014 12:14 PM, David Woodhouse wrote: > On Mon, 2014-04-07 at 16:43 -0400, Don Dutile wrote: >> >> Additionally, a tidbit of information like "some servers force NMI's >> on DMAR faults, >> and cause a system reset, thereby, preventing a kdump to occur" >> should have been included as one reason to stop DMAR faults from >> occurring on kexec-boot, >> in addition to the fact that a flood of them can lock up a system. > > How about allocating a physical scratch page, and setting up a mapping > for each device such that *every* virtual address (apart from those > listed in RMRRs, perhaps) is mapped to that same scratch page? > > That way you avoid the faults, but you also avoid stray DMA to parts of > the system that you don't want to get corrupted. > +1... more isolation as second kernel booting sounds good. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:48086 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756314AbaDHSoL (ORCPT ); Tue, 8 Apr 2014 14:44:11 -0400 Message-ID: <53444330.2030606@redhat.com> Date: Tue, 08 Apr 2014 14:42:56 -0400 From: Don Dutile MIME-Version: 1.0 To: David Woodhouse CC: Bill Sumner , indou.takao@jp.fujitsu.com, bhe@redhat.com, joro@8bytes.org, iommu@lists.linux-foundation.org, kexec@lists.infradead.org, alex.williamson@redhat.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, ishii.hironobu@jp.fujitsu.com, bhelgaas@google.com, doug.hatch@hp.com, zhenhua@hp.com Subject: Re: [PATCHv3 0/6] Crashdump Accepting Active IOMMU References: <1389391652-52422-1-git-send-email-bill.sumner@hp.com> <53430DE9.9080303@redhat.com> <1396973686.25235.36.camel@i7.infradead.org> In-Reply-To: <1396973686.25235.36.camel@i7.infradead.org> Content-Type: text/plain; charset=UTF-8; format=flowed Sender: linux-pci-owner@vger.kernel.org List-ID: On 04/08/2014 12:14 PM, David Woodhouse wrote: > On Mon, 2014-04-07 at 16:43 -0400, Don Dutile wrote: >> >> Additionally, a tidbit of information like "some servers force NMI's >> on DMAR faults, >> and cause a system reset, thereby, preventing a kdump to occur" >> should have been included as one reason to stop DMAR faults from >> occurring on kexec-boot, >> in addition to the fact that a flood of them can lock up a system. > > How about allocating a physical scratch page, and setting up a mapping > for each device such that *every* virtual address (apart from those > listed in RMRRs, perhaps) is mapped to that same scratch page? > > That way you avoid the faults, but you also avoid stray DMA to parts of > the system that you don't want to get corrupted. > +1... more isolation as second kernel booting sounds good.