Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753289Ab3GaT5A (ORCPT ); Wed, 31 Jul 2013 15:57:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2279 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760675Ab3GaT46 (ORCPT ); Wed, 31 Jul 2013 15:56:58 -0400 Date: Wed, 31 Jul 2013 15:56:23 -0400 From: Vivek Goyal To: Bjorn Helgaas Cc: Takao Indoh , "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , "open list:INTEL IOMMU (VT-d)" , "kexec@lists.infradead.org" , "ishii.hironobu@jp.fujitsu.com" , Don Dutile , "Sumner, William" , "alex.williamson@redhat.com" , Haren Myneni Subject: Re: [PATCH v2] PCI: Reset PCIe devices to stop ongoing DMA Message-ID: <20130731195622.GC1577@redhat.com> References: <51B93221.2040505@jp.fujitsu.com> <51BA7BB6.1080104@jp.fujitsu.com> <51EF7466.20703@jp.fujitsu.com> <51F5B966.9080405@jp.fujitsu.com> <51F758B6.9090204@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2548 Lines: 64 On Tue, Jul 30, 2013 at 09:59:16AM -0600, Bjorn Helgaas wrote: > On Tue, Jul 30, 2013 at 12:09 AM, Takao Indoh > wrote: > > (2013/07/29 23:17), Bjorn Helgaas wrote: > >> On Sun, Jul 28, 2013 at 6:37 PM, Takao Indoh wrote: > >>> (2013/07/26 2:00), Bjorn Helgaas wrote: > > >>>> My point about IOMMU and PCI initialization order doesn't go away just > >>>> because it doesn't fit "kdump policy." Having system initialization > >>>> occur in a logical order is far more important than making kdump work. > >>> > >>> My next plan is as follows. I think this is matched to logical order > >>> on boot. > >>> > >>> drivers/pci/pci.c > >>> - Add function to reset bus, for example, pci_reset_bus(struct pci_bus *bus) > >>> > >>> drivers/iommu/intel-iommu.c > >>> - On initialization, if IOMMU is already enabled, call this bus reset > >>> function before disabling and re-enabling IOMMU. > >> > >> I raised this issue because of arches like sparc that enumerate the > >> IOMMU before the PCI devices that use it. In that situation, I think > >> you're proposing this: > >> > >> panic kernel > >> enable IOMMU > >> panic > >> kdump kernel > >> initialize IOMMU (already enabled) > >> pci_reset_bus > >> disable IOMMU > >> enable IOMMU > >> enumerate PCI devices > >> > >> But the problem is that when you call pci_reset_bus(), you haven't > >> enumerated the PCI devices, so you don't know what to reset. > > > > Right, so my idea is adding reset code into "intel-iommu.c". intel-iommu > > initialization is based on the assumption that enumeration of PCI devices > > is already done. We can find target device from IOMMU page table instead > > of scanning all devices in pci tree. > > > > Therefore, this idea is only for intel-iommu. Other architectures need > > to implement their own reset code. > > That's my point. I'm opposed to adding code to PCI when it only > benefits x86 and we know other arches will need a fundamentally > different design. I would rather have a design that can work for all > arches. I agree. It makes sense to work on a design which works for all arches. And that's when I feel that handling this problem at IOMMU level makes more sense, if we can. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/