Re: [PATCH v11 00/11] iommu/arm-smmu-v3: Adopt the crashed kernel's stream table for kdump

[Nicolin Chen <nicolinc@nvidia.com>]

On Sat, Oct 17, 2026 at 04:19:20PM +0800, Shuai Xue wrote:
> We tested this series (v11, backported onto our 6.6-based kernel) on two
> arm64 server platforms that differ in how PCIe errors are reported: one
> with firmware-first reporting (GHES/CPER), the other with OS-first AER
> plus DPC. The test triggers a kdump crash (echo c > /proc/sysrq-trigger)
> on an otherwise idle machine and compares the capture kernel's dmesg
> between the unpatched baseline and the kernel carrying this series.
> 
> On the firmware-first platform (10 SMMUv3 instances):
> 
>   Unpatched, every SMMU logs:
> 
>     arm-smmu-v3.0.auto: SMMU currently enabled! Resetting...
> 
>   and the destructive reset immediately aborts in-flight DMA. The capture
>   kernel then drowns in a storm of GHES/CPER records together with PCIe
>   AER "Poisoned TLP" (Data Link Layer) errors from the devices that were
>   bus-mastering at crash time. Devices behind the reset SMMUs fail to
>   recover in the capture kernel, and in some runs the capture kernel
>   hangs in the error storm instead of saving the vmcore.
> 
>   With the series applied, all 10 SMMUs log:
> 
>     arm-smmu-v3.0.auto: kdump: retaining SMMUEN for in-flight DMA
> 
>   and the capture kernel boots with zero AER/GHES error records. A
>   complete vmcore is saved and the machine reboots normally.
> 
> On the OS-first AER/DPC platform (8 SMMUv3 instances):
> 
>   Unpatched: 8x "SMMU currently enabled! Resetting..." followed within
>   seconds by PCIe AER Completion Abort errors reported by the root
>   complex, along with DPC containment events and EDR notifications. The
>   NICs behind the contained link never recover in the capture kernel.
> 
>   With the series applied: 8x "kdump: retaining SMMUEN for in-flight DMA",
>   no PCIe error events at all, a complete vmcore and a clean reboot.
> 
> The baseline symptom is load-independent: it reproduces on idle machines,
> since even an idle server has periodic DMA in flight (NIC rings, NVMe
> admin queues, etc.).
> 
> Overall, on both platforms this series turns a capture-kernel boot that
> used to be buried under fatal PCIe error storms into a quiet one that
> reliably produces a usable vmcore.
> 
> Please feel free to add:
> 
> Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>

Thanks for the test report. I'll add your tag in v12 (on rc1).

Nicolin