On Fri, Jan 10, 2014 at 03:07:26PM -0700, Bill Sumner wrote: [..] > This patch set modifies the behavior of the iommu in the (new) crashdump kernel: > 1. to accept the iommu hardware in an active state, > 2. to leave the current translations in-place so that legacy DMA will continue > using its current buffers until the device drivers in the crashdump kernel > initialize and initialize their devices, > 3. to use different portions of the iova address ranges for the device drivers > in the crashdump kernel than the iova ranges that were in-use at the time > of the panic. Conceptually, above makes sense to me. I have few queries. - Do we need to pass any kind of data from first kernel to second kernel, like table size etc? Calgary IOMMU was using first kernel's tables also and it was determining previous kernel's table size using saved_max_pfn. - I don't know how IOMMU translation tables look like, but are new DMA zones setup by drivers in second kernel part of same table? How do we make sure that sufficient space is available. I am not sure if possible table corruption from crashed kernel is an issue here or not. In general, I think changelogs of these patches need to be little better. There seem to be lot of text and still I can't quickly wrap my head around what a particular patch is supposed to be doing. But we definitely need to fix this issue. IOMMU issues with kdump have been troubling us for a very long time. 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
