Khalid Aziz <[EMAIL PROTECTED]> writes: > Even though I agree with the philosophy that drivers should be able to > initialize devices in potentially hostile environment (and > "reset_device" should ultimately become unnecessary), there is still > some need to quiesce the devices before kexec'ing a new kernel. We are > already seeing problems with in-flight DMAs from non-quiesced devices > when a hardware I/O TLB is involved. It just makes me nervous to attempt > kexec a new kernel not knowing the system has quiet down. At the very > least, we should turn bus mastering off on all PCI devices to disable > any DMAs from them before we attempt kexec.
There is no guarantee that pci devices will actually stop the DMA when you disable bus mastering. If you don't have device specific code there is very little you can do reliably, because you don't have the errata work arounds. I agree that the IOTLB is an issue. The planned solution was to reserve an IOMMU window just for kdump in the primary kernel. (just as we do with memory addresses now). And only allow the dump kernel to use that window. We have never gotten as far as implementing the IOMMU reservation though :( Beyond that we can just as easily disable things on the way down as on the way up. A normal kexec does quiesce things. It is just the kexec on panic case where this is a problem. Precisely because we need to place a minimum amount of trust in the crasching kernel. Now if you want to quiesce devices on the way up, or in purgatory go right ahead. If you can do it generically it shouldn't be any harder there. But it is fundamental to the design that we avoid the problem of not quiescing devices instead of trying to solve it for the kexec on panic case. At the same time we avoid other issues by only reinitializing devices we care about in the recover kernel. Eric _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
