kernel/git/stable/linux.git/drivers/iommu/intel, branch master

Merge branches 'arm/smmu/updates', 'arm/smmu/bindings', 'mediatek', 'qualcomm/msm', 'rockchip', 'ti/omap', 'riscv', 'intel/vt-d', 'amd/amd-vi', 'core' and 'typos' into next

2026-08-11T07:12:19+00:00

iommu/vt-d: Flush context cache with correct SID when tearing down aliases

2026-08-10T08:04:09+00:00

domain_context_clear_one() and device_pasid_table_teardown() are both invoked once per DMA alias of a device. Each function locates the context entry using the bus/devfn pair provided by the pci_for_each_dma_alias() callback, then calls intel_context_flush_no_pasid(), which constructs a device-selective context-cache invalidation from info->bus and info->devfn (that is, always the requester ID of the device itself). As a result, for every alias other than the device’s own RID, the context entry that was just cleared in memory is never invalidated in the context cache. Hardware may continue using that stale cached entry. In the scalable-mode teardown path, intel_pasid_free_table() can then free the PASID directory still referenced by that stale entry, allowing the IOMMU to walk freed memory. Fix this by passing the source ID of the entry being torn down to intel_context_flush_no_pasid(), instead of deriving it from @info. Fixes: f90584f4beb84 ("iommu/vt-d: Add helper to flush caches for context change") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Reviewed-by: Samiullah Khawaja Signed-off-by: Joerg Roedel

iommu/vt-d: Tear down scalable-mode context on probe failure

2026-08-10T08:04:09+00:00

intel_pasid_setup_sm_context() walks a PCI device’s DMA aliases via pci_for_each_dma_alias() and programs a scalable-mode context entry for each RID. For a device with a dma_alias_mask, the callback is invoked once for the device’s own RID and once for each alias bit, all with the same pci_dev, so device_pasid_table_setup() runs for multiple RIDs. pci_for_each_dma_alias() stops at the first callback error. Therefore, a failure partway through the walk can leave context entries for already processed RIDs present and still pointing to the device’s PASID table. On this error path, intel_iommu_probe_device() currently jumps directly to intel_pasid_free_table(), which frees the PASID table without first tearing down those context entries. The IOMMU may then walk a present context entry whose PASID table pointer references freed memory. intel_iommu_release_device() already performs teardown before freeing the table. Apply the same ordering on the probe failure path. device_pasid_table_teardown() safely handles RIDs that were never programmed: iommu_context_addr() returns NULL when no context table has been allocated, and clearing the Present bit of an already non-present entry is a no-op. So unwind is safe for both the alias that failed and any aliases not yet reached. Fixes: 301f1a80487fd ("iommu/vt-d: Setup scalable mode context entry in probe path") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel

iommu/vt-d: Fix iopf_refcount leak on RID domain replacement

2026-08-10T08:04:09+00:00

intel_iommu_attach_device() enables IOPF for the new domain but never disables it for the old one. device_block_translation(), called at the start of the function, tears down translation but does not touch any IOPF state; blocking_domain_attach_dev() has to call iopf_for_domain_remove() explicitly before invoking it for exactly this reason. identity_domain_attach_dev() has the same problem. Its comment claims that no PRI handling is needed because the device has been put in the blocking state, but the blocking state and the IOPF reference count are independent of each other. As a result, replacing a domain that has an iopf_handler with another domain at RID level leaks a reference in info->iopf_refcount. The count never drops back to zero, so iopf_queue_remove_device() is never called and iommu_disable_pci_pri() triggers its WARN_ON(info->iopf_refcount) when the device is released. The PASID paths already handle this correctly by way of iopf_for_domain_replace(); convert the two RID paths to do the same. Using the replace helper rather than a bare remove keeps the enable before the disable, so the reference count does not transiently reach zero and evict the device from the IOPF queue. Fixes: 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel

iommu/vt-d: Clear Present bit before tearing down copied context entry

2026-08-10T08:04:08+00:00

copied_context_tear_down() zeroes the 128-bit context entry with context_clear_entry() while the Present bit is still set, and only then issues the context-cache and IOTLB invalidations. This leaves a window in which hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behaviour or spurious faults. While x86 provides strong write ordering, the compiler may reorder the writes to the two 64-bit halves of the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. There is no cacheline flush before the invalidation either, so on an IOMMU without coherent access to the context table the zeroed entry may not be visible to hardware at the point the invalidation is submitted. Apply the same ownership handshake described in the VT-d spec, Section 6.5.3.3 ("Guidance to Software for Invalidations"): clear only the Present bit, flush it out to the IOMMU, perform the invalidations, and only then zero the remainder of the entry. Fixes: c7191984e5aad ("iommu/vt-d: Factor out helpers from domain_context_mapping_one()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40linux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel

iommu/vt-d: Fix copied_tables bitmap leak on error in copy_translation_tables

2026-08-10T08:04:08+00:00

The iommu->copied_tables bitmap was introduced by the IOMMU live update series to track which context entries have been copied from the previous kernel. The allocation via bitmap_zalloc() was added inside copy_translation_tables(), but the error paths were not updated to free it: 1. When old_rt_phys is 0 (invalid root table address) 2. When memremap(old_rt_phys) fails 3. When kcalloc for ctxt_tbls fails (goto out_unmap, which only unmaps old_rt without releasing the bitmap) The bitmap is only cleaned up by free_dmar_iommu(), which is called from the free_iommu error label in init_dmars(). However, when copy_translation_tables() fails, init_dmars() does not jump to free_iommu -- it logs the error, falls through, and continues with the next IOMMU. As a result, copied_tables is leaked. Fix this by converting the two early returns to goto a new err_free_bitmap label, and by making out_unmap fall through to it so that the bitmap is always freed on any error path. The success path performs memunmap(old_rt) inline and returns 0 directly, since copied_tables must remain allocated for subsequent use. Signed-off-by: ZhaoJinming Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel

iommu/vt-d: Cache max domain ID to avoid redundant calculation

2026-08-10T08:04:08+00:00

The cap_ndoms() helper calculates the maximum available domain ID from the value of capability register, which can be inefficient if called repeatedly. Cache the maximum supported domain ID in max_domain_id field during initialization to avoid redundant calls to cap_ndoms() throughout the IOMMU driver. No functionality change. Signed-off-by: Lu Baolu Signed-off-by: Xu Yilun Reviewed-by: Kevin Tian Signed-off-by: Joerg Roedel

iommu/vt-d: Support the new DMA_REMAP_OPT_OUT flag bit

2026-08-10T08:04:07+00:00

Some BIOS already provides config options to expose/hide VT-d units as a whole to/from system software. A new demand is to allow exposing VT-d units but requesting system software to disable DMA remapping while sustaining interrupt remapping. This can be communicated now by setting the new DMA_REMAP_OPT_OUT flag bit in the DMAR table, as introduced in VT-d spec v5.2 (section 8.1, DMA Remapping Reporting Structure). Introduce a new off policy (DMAR_FW_OFF) for DMA_REMAP_OPT_OUT. As the strongest off policy, it cannot be overridden by user opts or any force_on types. If tboot is enabled in the meantime, kernel will panic. It is user responsibility to configure BIOS properly. One cleanup is left for future - the DMAR flag is parsed multiple times, in detect_intel_iommu(), dmar_platform_optin() (which can be called at run-time), etc. Caching it is a cleaner way. Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel

iommu/vt-d: Remove dmar_disabled

2026-08-10T08:04:06+00:00

It's replaced by dmar_policy_off() now, covering both "iommu=off" and "intel_iommu=off". Also remove unnecessary checks on no_iommu, leaving only one exception in intel_iommu_init() which skips debugfs init for "iommu=off" but not "intel_iommu=off". Keep it to avoid surprise for now. Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel

iommu/vt-d: Remove the 'force_on' variable

2026-08-10T08:04:06+00:00

The force_on variable is now redundant - same information captured by "dmar_policy == DMAR_FORCE_ON". Replace all force_on checks with dmar_policy_force_on(). Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel