kernel/linux.git/drivers/iommu/amd, branch v7.2-rc5

iommu/amd: Bound the early ACPI HID map

2026-07-21T11:34:46+00:00

The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry. Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter") Signed-off-by: Pengpeng Hou Reviewed-by: Ankit Soni Signed-off-by: Will Deacon

iommu/amd: Wait for completion instead of returning early in iommu_completion_wait()

2026-07-21T10:57:12+00:00

need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the "block until all previously queued commands have completed" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued. Signed-off-by: Guanghui Feng Fixes: 815b33fdc279 ("x86/amd-iommu: Cleanup completion-wait handling") Reviewed-by: Vasant Hegde Signed-off-by: Will Deacon

iommu/amd: Fix nested domain leak

2026-07-15T11:28:04+00:00

A couple of runs of different AI tools have generated something like the following bug report: In nested_domain_free(), when refcount_dec_and_test() returns false (other nested domains still reference the same gdom_info), the function returns without calling kfree(ndom), leaking the nested_domain structure. This problem wasn't introduced by this patch, but exists in the code from commit 757d2b1fdf5b that the patch modifies. Each nested_domain (ndom) is allocated individually in amd_iommu_alloc_domain_nested() via kzalloc_obj(*ndom). The .free callback is the sole point responsible for freeing this domain. When the refcount is > 0, only the xa_unlock_irqrestore is performed and the function returns, leaving ndom permanently allocated. This leak occurs every time a nested domain sharing a gDomID is destroyed while other domains still use that gDomID. There is a similar leak later in this function in the WARN_ON() test when the mapping is already NULL. Switch to a RAII-based cleanup for ndom, since it should always be freed in this function. Fixes: 757d2b1fdf5b ("iommu/amd: Introduce gDomID-to-hDomID Mapping and handle parent domain invalidation") Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Ankit Soni Signed-off-by: Will Deacon

iommu/amd: Fix IRQ unsafe locking in gdom allocation

2026-07-15T11:28:04+00:00

Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well. Fixes: 757d2b1fdf5b ("iommu/amd: Introduce gDomID-to-hDomID Mapping and handle parent domain invalidation") Signed-off-by: Tycho Andersen (AMD) Reviewed-by: Ankit Soni Signed-off-by: Will Deacon

Merge branches 'apple/dart', 'arm/smmu/updates', 'arm/smmu/bindings', 'rockchip', 'verisilicon', 'riscv', 'intel/vt-d', 'amd/amd-vi' and 'core' into next

2026-06-12T12:57:23+00:00

iommu/amd: Control INVALIDATE_IOMMU_PAGES PDE from the gather

2026-06-12T07:47:47+00:00

Now that AMD uses iommupt, it is easy to make use of the PDE bit. If the gather has no free list then no page directory entries were changed. Pass GN/PDE through the invalidation call chain in a u32 flags field that is OR'd into data[2] and set it properly from the gather. Signed-off-by: Jason Gunthorpe Reviewed-by: Wei Wang Tested-by: Dheeraj Kumar Srivastava Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel

iommu/amd: Make CMD_INV_IOMMU_ALL_PAGES_ADDRESS match the spec

2026-06-12T07:47:46+00:00

The spec in Table 14 defines the "Entire Cache" case as having the low 12 bits as zero. Indeed the command format doesn't even have the low 12 bits. Since there is only one user now, fix the constant to have 0 in the low 12 bits instead of 1 and remove the masking. Signed-off-by: Jason Gunthorpe Reviewed-by: Wei Wang Tested-by: Dheeraj Kumar Srivastava Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel

iommu/amd: Have amd_iommu_domain_flush_pages() use last

2026-06-12T07:47:18+00:00

Finish clearing out the size/last/end switching by converting amd_iommu_domain_flush_pages() to use last-based logic. This algorithm is simpler than the previous. Ultimately all this wants to do is select powers of two that are aligned to address and not longer than the distance to last. The new version is fully safe for size = U64_MAX and last = U64_MAX. Finally, the gather can be passed through natively without risking an overflow in (gather->end - gather->start + 1). Signed-off-by: Jason Gunthorpe Reviewed-by: Wei Wang Tested-by: Dheeraj Kumar Srivastava Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel

iommu/amd: Pass last in through to build_inv_address()

2026-06-12T07:18:59+00:00

This is the trivial call chain below amd_iommu_domain_flush_pages(). Cases that are doing a full invalidate will pass a last of U64_MAX. This avoids converting between size and last, and type confusion with size_t, unsigned long and u64 all being used in different places along the driver's invalidation path. Consistently use u64 in the internals. Signed-off-by: Jason Gunthorpe Tested-by: Dheeraj Kumar Srivastava Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel

iommu/amd: Simplify build_inv_address()

2026-06-12T07:17:05+00:00

This function is doing more work than it needs to: - iommu_num_pages() is pointless, the fls() is going to compute the required page size already. - It is easier to understand as sz_lg2, which is 12 if size is 4K, than msb_diff which is 11 if size is 4K. - Simplify the control flow to early exit on the out of range cases. - Use the usual last instead of end to signify an inclusive last address. - Use GENMASK to compute the 1's mask. - Use GENMASK to compute the address mask for the command layout, not PAGE_MASK. - Directly reference the spec language that defines the 52 bit limit. No functional change intended. Signed-off-by: Jason Gunthorpe Reviewed-by: Wei Wang Tested-by: Dheeraj Kumar Srivastava Reviewed-by: Vasant Hegde Signed-off-by: Joerg Roedel