Re: [PATCH v1] iommu: Skip mapping at address 0x0 if it already exists

[Jason Gunthorpe <jgg@ziepe.ca>]

On Sun, Feb 22, 2026 at 12:50:50AM +0100, Antheas Kapenekakis wrote:
> Commit 789a5913b29c ("iommu/amd: Use the generic iommu page table")
> introduces the shared iommu page table for AMD IOMMU. Some bioses
> contain an identity mapping for address 0x0, which is not parsed
> properly (e.g., certain Strix Halo devices). This causes the DMA
> components of the device to fail to initialize (e.g., the NVMe SSD
> controller), leading to a failed post.

I'm trying to understand the issue here, is it that the old AMD code
incorrectly succeeded iommu_map() on top of an existing mapping while
the new code returns -EADDRINUSE?

Then the existing guard for double mapping doesn't work since 0 is an
ambiguous return?

> @@ -1224,6 +1224,11 @@ static int iommu_create_device_direct_mappings(struct iommu_domain *domain,
>  				ret = iommu_map(domain, addr - map_size,
>  						addr - map_size, map_size,
>  						entry->prot, GFP_KERNEL);
> +				if (ret == -EADDRINUSE && addr - map_size == 0) {
> +					dev_warn_once(dev,
> +						"iommu: identity mapping at addr 0x0 already exists, skipping\n");
> +					ret = 0;
> +				}

Nothing else prints here, so I wouldn't print either..

Apparently we just silently ignore if the BIOS creates conflicting
mappings for some reason..

I think it is OK to just ignore EADDRINUSE always, it unambigously
means a mapping is present and the intention of this logic is to
ignore double mappings to the same IOVA.

The cleaner fix is to correct the return code of iommu_iova_to_phys()
or to make EADDRINUSE reliable and remove the iommu_iova_to_phys(),
those are both a lot of trouble so I think this proposed single if is
reasonabe. Just please clean up the commit message to be a bit clearer
on what caused this regression and add a short comment above the new if:

 0 return from iommu_iova_to_phys() is ambiguous, it could mean a
 present mapping. EADDRINUSE is reliable when supported, it means the
 IOVA is already mapped, so ignore it to resolve the ambiguity.

Thanks,
Jason