summaryrefslogtreecommitdiff
path: root/scripts/basic
diff options
context:
space:
mode:
authorFederico Parola <fparola@amazon.de>2026-09-10 15:04:47 +0000
committerJoerg Roedel <joerg.roedel@amd.com>2026-09-24 13:53:36 +0200
commitaa416fa911ad67090291e39432560091f6ae9711 (patch)
treef0d69cbcf1ea34e5b1a0cd7f7e88e92fd6b7f0e4 /scripts/basic
parent183629813e2c57bc6cd75ebb5e0414df775f1c5b (diff)
downloadlinux-aa416fa911ad67090291e39432560091f6ae9711.tar.gz
linux-aa416fa911ad67090291e39432560091f6ae9711.zip
iommu: Finalize deferred attachments when mapping MSI pages
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> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Diffstat (limited to 'scripts/basic')
0 files changed, 0 insertions, 0 deletions