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

[Will Deacon]

On Sun, Oct 04, 2026 at 01:59:04PM -0700, Nicolin Chen wrote:
> On Sun, Oct 04, 2026 at 01:35:01PM -0300, Jason Gunthorpe wrote:
> > On Sun, Oct 04, 2026 at 02:25:07PM +0100, Will Deacon wrote:
> > > > + *  - 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.
> 
> I agree that it's safer to defer that to a followup series. It
> also needs someone who has a non-coherent HW for a full test.
> 
> On the other hand, this series is tested by folks from multiple
> organizations, so it's really a needed and verified one.

I wasn't disputing that, though. I'm saying that it's half finished
without the non-coherent part, so I'd like to understand what's needed
to add that. Can you please explain what is needed beyond using
MEMREMAP_WC? That maps to Normal-NC on arm64, just like the DMA API does.

Will