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

[Mostafa Saleh]

On Tue, Jun 30, 2026 at 03:59:42PM -0300, Jason Gunthorpe wrote:
> 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 :)

I hope not! Although memory corruption can happen due to many other
reasons :/

I am not trying to bikeshed, but I wondering if there is a more
reliable way rather than doing archaeology from a panicked kernel
SMMUv3 configuration, as I am worried that will be even harder to
debug if it goes wrong.

>  
> > 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.

Ideally if a TLB is to be missed (because of the panic), it should not
point to kdump memory as it is carved-out. However, it is still a leap to
assume that the TLBs are in a good shape as I mentioned with RPM (or
even if the device resets transiently for some reason) it can end up
with garbage in its TLBs.

Thanks,
Mostafa

> 
> Jason