Re: [PATCH] iommu/arm-smmu-v3: Allow disabling Stage 1 translation

[Will Deacon <will@kernel.org>]

On Wed, Apr 22, 2026 at 01:23:51PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 22, 2026 at 06:44:31AM +0000, Evangelos Petrongonas wrote:
> > The motivation is live update of the hypervisor: we want to kexec into a
> > new kernel while keeping DMA from passthrough devices flowing, which
> > means the SMMU's translation state has to survive the handover. The Live
> > Update Orchestrator work [1] and the in-progress  "iommu: Add live
> > update state preservation" series [2] are building exactly this plumbing
> > on top of KHO; [2]'s cover letter calls out Arm SMMUv3 support as future
> > work, and an earlier RFC from Amazon [3] sketched the same idea for
> > iommufd.
> 
> It would be appropriate to keep this patch with the rest of that out
> of tree pile, for example in the series that enables s2 only support
> in smmuv3.
> 
> > For this use case, Stage 2 is materially easier to persist than Stage 1,
> > for structural rather than performance reasons: 
> 
> I don't think so. The driver needs to know each and every STE that
> will survive KHO. The ones that don't survive need to be reset to
> abort STEs. From that point it is trivial enough to include the CD
> memory in the preservation.
> 
> It would help to send a preparation series to switch the ARM STE and
> CD logic away from dma_alloc_coherent and use iommu-pages instead,
> since we only expect iommu-pages to support preservation..

Does iommu-pages provide a mechanism to map the memory as non-cacheable
if the SMMU isn't coherent? I really don't want to entertain CMOs for
the queues.

Will