On Thu, Aug 01, 2013 at 03:34:06PM +0900, Takao Indoh wrote: > (2013/08/01 6:23), Rafael J. Wysocki wrote: > > On Wednesday, July 31, 2013 03:08:03 PM Bjorn Helgaas wrote: > >> [+cc Rafael, linux-acpi] > >> > >> On Tue, Jul 30, 2013 at 6:35 PM, Takao Indoh <indou.takao@xxxxxxxxxxxxxx> wrote: > >> > >>> On x86, currently IOMMU initialization run *after* PCI enumeration, but > >>> what you are talking about is that it should be changed so that x86 > >>> IOMMU initialization is done *before* PCI enumeration like sparc, right? > >> > >> Yes. I don't know whether or when that initialization order will ever > >> be changed, but I do think we should avoid building more > >> infrastructure that depends on the current order. > >> > >> Changing the order is a pretty big deal because it's a lot more than > >> just the IOMMU. Basically I think we should be enumerating ACPI > >> devices, including the IOMMU, before PCI devices, but there's a lot of > >> legacy involved in that area. Added Rafael in case he has any > >> thoughts. > > > > Well, actually, I'm not really familiar with IOMMUs, sorry. > > > > I do think that initializing IOMMU before PCI enumeration would be better, > > however. At least if the ordering should be the same on all architectures, > > which I suppose is the case, that's the one I'd choose. > > Ok guys. If x86 IOMMU maintainer also thinks changing order is > necessary, maybe I need to give up device reset in kdump kernel and > consider doing it in panic kernel. I don't think trying to reset all the devices in panic kernel is a good idea. We need to handle the problem at IOMMU level first which is independent of whether devices have been reset or not. IOW, we should have the capability to initialize IOMMU first and be able to deal with devices which are doing DMA. I am not against doing device reset and it most likely is a good thing but it should happen in second kernel and not in crashed kernel. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
