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

[Jason Gunthorpe]

On Thu, Jul 02, 2026 at 12:25:43PM -0700, Nicolin Chen wrote:
> 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.

You will also have to change things to allocate the kernel global vmid
from the IDR, it will usually be 0 but not for kdump. Then you have to
find all the places where the 0 is implicitly placed and put in the
actual value.
 
> 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..

Yeah, I would limit to S2 for now

Jason