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

[Pranjal Shrivastava]

On Wed, Jul 01, 2026 at 01:05:19PM +0000, Mostafa Saleh wrote:
> 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.

Regarding RPM, I can say that even if we panicked while SMMU was off in
the previous kernel, when we call device_reset() in the new kernel we
still issue the TLBI_ALL with the reset.

However, I agree with the overall problem, i.e. IF an active device
unmaps the DMA addr after the transaction in the previous kernel, 
(with the SMMU powered ON) but the TLBI was missed due to a crash/panic,
Any new DMA in the new kernel may alias onto a memory in the previous 
(crashed) kernel, not the kdump kernel.

That way, I agree that continuing DMA could be problematic as we may
corrupt the very memory we'd wanna analyze for a crash.

Thanks,
Praan