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

[Nicolin Chen]

On Fri, Jul 03, 2026 at 08:57:16AM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 02, 2026 at 08:32:44PM -0700, Nicolin Chen wrote:
> > On Thu, Jul 02, 2026 at 08:50:04PM -0300, Jason Gunthorpe wrote:
> > > 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:
> > > > > 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.
> > 
> > Hmm, I just realized that all the EL2 commands do not take VMID.
> 
> If the EL2 commands are being used then there is no S2 support and no
> VMID support.
> 
> So if you disable kdump when S2 is not supported it also disables it
> when EL2 would be used, which effectively means it is not supported in
> a VM.

Hmm, they are actually not exclusive: e.g. Grace has both.

EL2 is from FEAT_E2H, which is set when
 1. IDR0.HYP=1
 2. cpus_have_cap(ARM64_HAS_VIRT_HOST_EXTN)

VMID is from FEAT_TRANS_S2, which is set When
 1. IDR0_S2P=1

So, host-level stage-1 TLBIs use EL2 commands (no VMID); guest-level
TLBIs use NH_ commands (with VMID).

Scanning through CDs seems inevitable...

Thanks
Nicolin