Re: [PATCH v10 06/13] iommu/arm-smmu-v3: Add ARM_SMMU_OPT_KDUMP_ADOPT for kdump kernel
From: Nicolin Chen
Date: Sun Oct 04 2026 - 16:59:30 EST
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.
Thanks
Nicolin