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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Feb 24, 2026 at 08:33:50PM +0100, Antheas Kapenekakis wrote:
> On Tue, 24 Feb 2026 at 20:23, Jason Gunthorpe <jgg@ziepe.ca> 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.

I checked the old AMD driver it is definately returning 0 from
iommu_iova_to_phys(), so that hasn't changed.

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

I think it is a good solution as-is, I just want clarity on what
actually regressed here, and I think it is that iommu_map() behavior
changed.

Jason