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

[Pranjal Shrivastava <praan@google.com>]

On Tue, Jun 30, 2026 at 03:33:12PM +0000, Mostafa Saleh wrote:
> On Tue, Jun 30, 2026 at 02:51:40PM +0000, Pranjal Shrivastava wrote:
> > On Tue, Jun 30, 2026 at 01:17:30PM +0000, Mostafa Saleh wrote:
> > > On Mon, Jun 29, 2026 at 11:15:33PM -0700, Nicolin Chen wrote:
> > > > When transitioning to a kdump kernel, the primary kernel might have crashed
> > > > while endpoint devices were actively bus-mastering DMA. Currently, the SMMU
> > > > driver aggressively resets the hardware during probe by clearing CR0_SMMUEN
> > > > and setting the Global Bypass Attribute (GBPA) to ABORT.
> > > > 
> > > > In a kdump scenario, this aggressive reset is highly destructive:
> > > > a) If GBPA is set to ABORT, in-flight DMA will be aborted, generating fatal
> > > >    PCIe AER or SErrors that may panic the kdump kernel
> > > 
> > > Can you please clarify more on those errors, what conditions will
> > > trigger that?
> > > For example, patch 4 disables the EVTQ to avoid events as there might
> > > be a lot, why are they not fatal also?
> > > 
> > > > b) If GBPA is set to BYPASS, in-flight DMA targeting some IOVAs will bypass
> > > >    the SMMU and corrupt the physical memory at those 1:1 mapped IOVAs.
> > > > 
> > > > To safely absorb in-flight DMA, the kdump kernel must leave SMMUEN=1 intact
> > > > and avoid modifying STRTAB_BASE. This allows HW to continue translating in-
> > > > flight DMA using the crashed kernel's page tables until the endpoint device
> > > > drivers probe and quiesce their respective hardware.
> > > > 
> > > > However, the ARM SMMUv3 architecture specification states that updating the
> > > > SMMU_STRTAB_BASE register while SMMUEN == 1 is UNPREDICTABLE or ignored.
> > > > 
> > > > This leaves a kdump kernel no choice but to adopt the stream table from the
> > > > crashed kernel.
> > > 
> > > In many cases the patches assume that the CDs/STE might be corrupted,
> > > but still attempt to retrieve them with some validation
> > > (log2size/split...)
> > > However, the base address might be broken, TLBs state is unknown...
> > > 
> > > IMO, although that might improve the status quo, there are still
> > > heuristics, in addition to noticeable complexity to transition the
> > > stream tables. I wonder if FW can deal with AER in that case before
> > > booting the kdump kernel.
> > 
> > I guess we're reading the base address from the HW register itself so
> > that should be fine? CDs are in-memory so that's why they could be
> > corrupted?
> 
> 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.
> 
> > 
> > About the TLB state, I'm not sure what might pollute it, since this is a
> > kexec, I don't expect any non-kernel entity to gain program control
> > before the kdump kernel.. Hence, IMO, we can't configure FW to deal with
> > AER here..
> 
> 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?
> 
> Why can't the FW deal with it?

The FW can't handle it because between a kexec from main kernel -> kdump
there's no FW-based handoff hence wee can't setup a handler in FW..

> As I mentioned above in the previous
> reply I am not sure I understand what situation leads into this, when
> does a device trigger SError to the system vs when not which is observed
> as an event in that case.
> 

Ack. I see what you mean now.. How does a DMA fault raise an SError? 

I'm guessing the HW (PCIe RC) is wired in a way to raise an SError on an
error? But I agree that sounds pretty unusual, why should a DMA abort
panic the CPU? Is the DMA happening between a platform device & PCIe EP?
Even if that's true, why would it raise an SError? (No CPU was involved)
Unless, we have a fabric that raises an Serror on a SLVERR or something

Thanks,
Praan