Re: [PATCH rc v7 0/7] iommu/arm-smmu-v3: Fix device crash on kdump kernel

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Jun 30, 2026 at 03:33:12PM +0000, Mostafa Saleh wrote:

> For example patch#1 verifies log2size and split and both are read
> from HW registers. Same for the base address or other addresses as
> the page tables, they  might be corrupted due to a buggy driver.
> My point is that, it is really hard to assume that the previous state
> of registers/STE/page-tables were valid or even consistent, when the
> kernel crashed and did not transition the state gracefully.

Sure, and this mechanism is probably not very useful for debugging
these kinds of errors in the SMMU driver. Oh well, that isn't a common
source of kernel crashes :)
 
> Similarly for TLBs, the kernel might have panicked in the middle of an
> unmap or free domain. (not to mention what that means for RPM where
> a device reset with unknown TLBs)

TLB is fine. kdump works by carving out a chunk of memory for the
future crash kernel. When the kernel boots it ignores all the memory
used by the prior kernel. So DMA can keep running into the old kernels
memory with no issue. It doesn't matter if the TLBs are inconsistent or
not.

Jason