[PATCH v2] iommu: Finalize deferred attachments when mapping MSI pages

[Federico Parola <fparola@amazon.de>]

When a device's attachment to its default domain is deferred, the IOMMU
is still translating the device with the tables inherited from the
previous kernel. Any mapping installed in that domain does not take
effect until the deferred attachment is finalized.

iommu_deferred_attach() covers the DMA mapping paths, but nothing covers
iommu_dma_prepare_msi(): programming an MSI installs the MSI page in
group->domain and hands the resulting IOVA to the irqchip, so an MSI
programmed before the first DMA map is written using an IOVA that the
hardware does not yet translate.

This issue is currently not triggerable as the two IOMMU implementations
supporting deferred attachments, Intel and AMD, do not rely on DMA
translations for MSI transactions. However, the Arm implementation being
introduced in [1] will be subject to it.

Finalize the deferred attachment from iommu_dma_prepare_msi() too,
before the MSI page is mapped. Do it outside group->mutex, as
iommu_deferred_attach() takes the mutex itself and the two operations do
not need to be atomic with respect to each other: if an attach replaces
group->domain in between, the MSI page is mapped into whatever
group->domain holds once the mutex is taken.

iommu_get_domain_for_dev() cannot return NULL here: MSI setup only runs
for a device whose driver is bound, and of_iommu_configure() and
acpi_iommu_configure_id() hold the bind off until the IOMMU is
registered, hence until iommu_device_register() has set up the group's
default domain. group->domain then stays non-NULL until
iommu_deinit_device() clears it once the group is empty.
dma_iova_try_alloc() already relies on the same guarantee.

The static key gating the iommu_deferred_attach() calls in dma-iommu.c
is private to that file, and replicating it here is not worthwhile since
MSI page mapping is not a fast path.

The behaviour of a rejected attach changes slightly: an attach refused
because the device is being reset (-EBUSY) now fails MSI setup rather
than only the first DMA map.

Link: https://lore.kernel.org/linux-iommu/cover.1788130528.git.nicolinc@nvidia.com/ [1]
Assisted-by: Claude:claude-opus-5
Signed-off-by: Federico Parola <fparola@amazon.de>
---
Changes in v2:
- Moved up iommu_deferred_attach() from iommu_dma_sw_msi() to
  iommu_dma_prepare_msi() and removed unlocked variant of the function.
- Link to v1: https://lore.kernel.org/linux-iommu/20260910115152.54108-1-fparola@amazon.de
---
 drivers/iommu/iommu.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index cd1bca7ede9a..b486b8bbd1fc 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -4243,6 +4243,10 @@ int iommu_dma_prepare_msi(struct msi_desc *desc, phys_addr_t msi_addr)
 	if (!group)
 		return 0;
 
+	ret = iommu_deferred_attach(dev, iommu_get_domain_for_dev(dev));
+	if (ret)
+		return ret;
+
 	mutex_lock(&group->mutex);
 	/* An IDENTITY domain must pass through */
 	if (group->domain && group->domain->type != IOMMU_DOMAIN_IDENTITY) {
-- 
2.47.3