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

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

On 10/09/2026 4:04 pm, Federico Parola wrote:
> 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.

I know there are drivers which explicitly test MSI delivery when 
starting up, and it's reasonable that they might do so before any 
explicit DMA API operation, so this seems fair to me.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

> 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) {