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

[Jason Gunthorpe]

On Sun, Oct 04, 2026 at 02:25:07PM +0100, Will Deacon wrote:
> >  drivers/iommu/arm/arm-smmu-v3/Makefile        |   1 +
> >  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h   |  21 ++
> >  .../iommu/arm/arm-smmu-v3/arm-smmu-v3-kdump.c | 229 ++++++++++++++++++
> 
> Please don't put this here. The live update / handover stuff is going to
> need very similar logic (see the RFC from Pranjal) and I don't fancy
> having to rename or resplit this file when that comes along.

Ah, I was thinking we'd put most of that stuff in here, but a kexec
name would probably be nicer.

> > + * Note:
> > + *  - Adoption only starts on an SMMU that the crashed kernel left enabled, as a
> > + *    disabled SMMU (CR0_SMMUEN=0) could hold meaningless register values.
> > + *  - Values read from the crashed kernel's registers get structural validation
> > + *    only (format, size, span, alignment, and ID range); the physical addresses
> > + *    are not vetted, as the kdump kernel has no record of which pages held the
> > + *    tables.
> 
> Can we at least check that they don't point at the kdump region?

I don't think it is necessary, I  was on the fence about all this
exisitng validation even in the first place.

Is there any easy way to do it?
 
> > + *  - A structural inconsistency at adoption time tosses the entire adoption and
> > + *    makes the SMMU fall back to a full reset blocking in-flight DMAs.
> > + *  - L2 stream tables are adopted lazily at master-inserting time, to bound the
> > + *    peak memory use against a corrupted L1 table; any lazy L2 adoption failure
> > + *    rejects that device alone, as its blast radius is bounded to the bus.
> > + *  - Only a coherent SMMU (ARM_SMMU_FEAT_COHERENCY) is supported, as the stream
> > + *    table adoption is done by memremap with MEMREMAP_WB, which is verified on
> > + *    the real hardware. Callers of these functions are responsible for gating
> > + *    ARM_SMMU_FEAT_COHERENCY once during the probe.
> 
> This is an artificial restriction and not one that I'm wild about for kdump:
> we should be able to support this for non-coherent SMMUs as well. Is there
> anything more to it than using MEMREMAP_WC in that case?
 
I've forgotten why it ended up like this, it was some complication
that seemed hard.. MEMREMAP_WC is not the same attribute dma coherent
would have used, I'm not sure we have the right stuff to be able to
flush any write combining buffer? I'm nervous about that at least.

Remember this is not just reading it but it has to operate like this
after the fact. In handover you wanted to use the dma cohernent
preservation.

So, I think this restriction is mostly a lack of the right MEMREMAP
flag? It is not insovlable just work outside the scope of this series.

Jason