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

[Nicolin Chen <nicolinc@nvidia.com>]

On Thu, Jul 02, 2026 at 11:41:57AM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 01, 2026 at 01:36:29PM +0000, Pranjal Shrivastava wrote:
> 
> > 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.
> 
> It looks like there is an issue in this series, it isn't doing
> anything with the VMIDs.
> 
> The VMIDs that are in-used by the adopted stream table have to be
> removed from the idr as well (and similarly for ASID if we don't have
> VMID HW support).
> 
> Then the VMIDs that may be dirtied by the prior kernel remain isolated
> and are never re-used by the new kernel. When the new kernel wants to
> do DMA it will replace the STE with a new, clean VMID, and there is no
> problem.

I see. I assume the reserved VMID for the kdump kernel will be a
clean VMID (!=0). That should guarantee different cache tags.

But, do we have to scan CDs for ASID? I wonder if we could limit
to ARM_SMMU_FEAT_TRANS_S2 only, as this series does not memremap
CDs at all..

Nicolin