Re: [PATCH v11 06/11] iommu/arm-smmu-v3: Add ARM_SMMU_OPT_KDUMP_ADOPT for kdump kernel

From: Jason Gunthorpe

Date: Tue Oct 20 2026 - 10:59:01 EST


On Tue, Oct 20, 2026 at 11:38:21AM +0000, Mostafa Saleh wrote:
> > +int arm_smmu_kdump_adopt_strtab(struct arm_smmu_device *smmu)
> > +{
> > + u32 cfg_reg = readl_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE_CFG);
> > + u64 base_reg = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE);
> > + bool was_2lvl = smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB;
> > + phys_addr_t base = base_reg & STRTAB_BASE_ADDR_MASK;
> > + u32 fmt = FIELD_GET(STRTAB_BASE_CFG_FMT, cfg_reg);
> > + int ret;
> > +
> > + dev_dbg(smmu->dev, "adopting crashed kernel's stream table\n");
> > +
> > + if (fmt == STRTAB_BASE_CFG_FMT_2LVL) {
> > + /*
> > + * Both kernels run on the same hardware, so it's impossible for
> > + * kdump kernel to see the support for linear stream table only.
> > + */
>
> STRTAB_SPLIT which influences ARM_SMMU_FEAT_2_LVL_STRTAB is a SW choice, so it is
> possible to get such mismatch if STRTAB_SPLIT of the newer kernel is larger than the
> older kernel.
> However, I agree that in that case it's better to refuse the adoption.

Yeah this is one of those sneaky ABIs I was talking about for live
update.

Presumably we will eventually have to make this fully dynamic so the
successor can process everything the HW supports.

Jason