> Hi, there are some previous works about this issue, reset PCI devices > in kdump kernel to stop ongoing DMA: > > [v7,0/5] Reset PCIe devices to address DMA problem on kdump with iommu > https://lore.kernel.org/patchwork/cover/343767/ > > [v2] PCI: Reset PCIe devices to stop ongoing DMA > https://lore.kernel.org/patchwork/patch/379191/ > > And didn't get merged, that patch are trying to fix some DMAR error > problem, but resetting devices is a bit too destructive, and the > problem is later fixed in IOMMU side. And in most case the DMA seems > harmless, as they targets first kernel's memory and kdump kernel only > live in crash memory. I was going to ask the same. If the kdump kernel had IOMMU on, would that still be a problem? > Also, by the time kdump kernel is able to scan and reset devices, > there are already a very large time window where things could go > wrong. > > The currently problem observed only happens upon kdump kernel > shutdown, as the upper bridge is disabled before the device is > disabledm so DMA will raise error. It's more like a problem of wrong > device shutting down order. The way it was described earlier "During this time, the SUT sometimes gets a PCI error that raises an NMI." suggests that it isn't really restricted to kexec/kdump. Any attached device without an active driver might attempt spurious or malicious DMA and trigger the same during normal operation. Do you have available some more reporting of what happens during the PCIe error handling? "The reaction to the NMI that the kdump kernel takes is problematic." Or the NMI should not have been triggered to begin with? Where does that happen? I couldn't access the bug report. -Deepa _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
