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

[Robin Murphy <robin.murphy@arm.com>]

On 2026-04-22 5:23 pm, 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.

Or even better, just make sure that whatever hypervisor supports this 
half-finished WIP mechanism also uses IOMMU_HWPT_ALLOC_NEST_PARENT to 
explicitly get stage 2 domains for VM-assigned devices in the first 
place, rather than swing a big hammer at the kernel (that takes out 
SVA/PASID support as collateral damage...)

Thanks,
Robin.

>> 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..
> 
> I could maybe see only supporting non-PASID as a first-series, but a
> CD table with SSID 0 only populated is still pretty trivial.
> 
> Jason