Re: [PATCH v8 0/9] iommu/arm-smmu-v3: Adopt the crashed kernel's stream table for kdump

[Pranjal Shrivastava]

On Fri, Jul 10, 2026 at 05:52:41PM -0700, Nicolin Chen wrote:

Hi Nicolin,

> 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
> 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 this series:
>  - Introduce an ARM_SMMU_OPT_KDUMP_ADOPT
>  - Skip SMMUEN and STRTAB_BASE resets in arm_smmu_device_reset()
>  - Skip EVENTQ/PRIQ setup including interrupts and their handlers
>  - Memremap the crashed kernel's stream tables into the kdump kernel [*]
>  - Reserve the crashed kernel's in-use ASIDs and VMIDs, preventing any TLB
>    aliasing with the kdump kernel's own domains
>  - Defer any default domain attachment to retain STEs until device drivers
>    explicitly request it.
> Most of the kdump code is added to a new arm-smmu-v3-kdump.c that is only
> built when CONFIG_CRASH_DUMP is enabled.
> 
> [*] For verification reasons, this series only fixes coherent SMMUs.
> 
> For non-ARM_SMMU_OPT_KDUMP_ADOPT cases, keep a status quo since the commit
> 3f54c447df34f ("iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel"):
> full reset followed by driver-initiated reattach, potentially rejecting any
> in-flight DMA.
> 
> Note that this series is no longer treated as a bug fix, since it has grown
> fairly big and most of the kdump code now resides in a separate file. For
> folks interested in back-porting the change: a v6.12+ kernel (since commit
> 85196f54743d ("iommu/arm-smmu-v3: Reorganize struct arm_smmu_strtab_cfg"))
> would be still compatible with this series.
>

[...]

> 
> Nicolin Chen (9):
>   iommu/arm-smmu-v3: Do not enable EVTQ/PRIQ interrupts in kdump kernel
>   iommu/arm-smmu-v3: Skip EVTQ/PRIQ setup in kdump kernel
>   iommu/arm-smmu-v3: Add ARM_SMMU_OPT_KDUMP_ADOPT for kdump kernel
>   iommu/arm-smmu-v3: Destroy vmid_map ida via devres
>   iommu/arm-smmu-v3-kdump: Reserve crashed kernel's ASIDs and VMIDs
>   iommu/arm-smmu-v3-kdump: Implement is_attach_deferred()
>   iommu/arm-smmu-v3: Retain CR0_SMMUEN during kdump device reset
>   iommu/arm-smmu-v3: Skip RMR bypass for kdump adoption
>   iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP_ADOPT in probe()
> 
>  drivers/iommu/arm/arm-smmu-v3/Makefile        |   1 +
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  48 ++
>  .../iommu/arm/arm-smmu-v3/arm-smmu-v3-kdump.c | 579 ++++++++++++++++++
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 246 ++++++--
>  4 files changed, 806 insertions(+), 68 deletions(-)
>  create mode 100644 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-kdump.c

This series seems to align with the restore part of my SMMUv3 Live Update
(Kexec Handover) support. I have a WIP series in dev on github:
https://github.com/pran005/linux/tree/wip-arm-smmu-lu 

While going through the Stream Table adoption code in this series, I 
realized there is significant overlap between how kdump adopts a crashed
kernel's SMMU structures and how we restore preserved SMMU state via 
Kexec HandOver (KHO) during a live update

For e.g., the KHO preservation hook in my series explicitly tracks and
serializes the physical addresses of all active L1/L2 tables into the 
KHO Device Tree so the incoming kernel can kho_restore them.

However, looking at your approach, I think I can slightly rework my 
preservation logic and instead of bloating the KHO ABI with physical
addresses, I could re-use your exact table-walking logic during probe
to parse the live L1/L2 structures directly from registers, identify 
the valid tables, and kho/dma_restore them. There could me small 
differences though, for example instead of memremap stuff, we'd have to
use the kho/dma_restore API (which can be done by passing some op like 
the data structure writers we have?) Similarly, maybe reserving ASID/VMID 
can be potentially re-used as well..

Since, I plan to introduce another file: arm-smmu-v3-liveupdate.c and
given how much of this adoption and restoration logic is re-usable 
(parsing STRTAB_BASE, walking the L1 array, restoring L2s (not deferred
for KHO), I wanted to start a discussion to see if it makes sense to 
factor this common code out into an arm-smmu-v3-kexec.c (or similar)?

I'm not trying to delay this series by any chance and I would be more
than happy to rebase my Live Update series on top of this series and
refactor to share this core logic between the 2 new files: 
arm-smmu-v3-kdump.c & arm-smmu-v3-liveupdate.c 

I just wanted to start and early discussion since there's some overlap
and align on a way forward.

Thanks,
Praan