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

[Antheas Kapenekakis]

On Tue, 24 Feb 2026 at 20:23, Jason Gunthorpe <jgg@xxxxxxxx> wrote:
>
> 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?

Hi Jason,

It seems like the previous code correctly handled the 0 case, and the
new code does not due to the 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..

It seems like multiple DMA devices get a shared memory space, so
applying the mappings multiple times is expected. The problem is
handling the 0 address.

> 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.

If you think that this patch is a long term solution, I can drop the
print, the addr == 0 check, add a comment on top, then repost a V2
with an updated description to be more concrete.

Best,
Antheas

> Thanks,
> Jason
>