Seeing as translations are pre-enabled, all devices will be set for
deferred attach. The deferred attached actually has to be done when
doing DMA mapping for devices to work.

There may be a better way to do this be, for example, consulting the
context entry table and only deferring attach if there is a persisted
context table entry for this device.
---
 drivers/iommu/dma-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index e5d087bd6da1..76f916848f48 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1750,7 +1750,7 @@ void iommu_dma_compose_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
 
 static int iommu_dma_init(void)
 {
-	if (is_kdump_kernel())
+	if (is_kdump_kernel() || liveupdate)
 		static_branch_enable(&iommu_deferred_attach_enabled);
 
 	return iova_cache_get();
-- 
2.40.1

On Mon, Feb 05, 2024 at 12:01:56PM +0000, James Gowans wrote:
> Seeing as translations are pre-enabled, all devices will be set for
> deferred attach. The deferred attached actually has to be done when
> doing DMA mapping for devices to work.

This shouldn't be part of your solution..

A DMA API using driver should never be attached to a device that is
being persisted across a kexec. If it does then the device should be
fully reset and re-attached to the normal DMA API iommu domain.

You should be striving to have an iommu_domain to represent the
special post-kexec translation regime.

Jason