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

[Nicolin Chen]

On Mon, Oct 05, 2026 at 07:34:25AM +0100, Will Deacon wrote:
> 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.

I am not aware of anything beyond MEMREMAP_WC.

It should likely need a helper to select flag:
  ARM_SMMU_FEAT_COHERENCY ? MEMREMAP_WB : MEMREMAP_WC
and a verification on a non-coherent SMMU.

Thanks
Nicolin