[PATCH v3] iommu: Fix mapping check for 0x0 to avoid re-mapping it

[PATCH v3] iommu: Fix mapping check for 0x0 to avoid re-mapping it

[Antheas Kapenekakis]

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.

Specifically, on the GPD Win 5, the NVME and SSD GPU fail to mount,
making collecting errors difficult. While debugging, it was found that
a -EADDRINUSE error was emitted and its source was traced to
iommu_iova_to_phys(). After adding some debug prints, it was found that
phys_addr becomes 0, which causes the code to try to re-map the 0
address and fail, causing a cascade leading to a failed post. This is
because the GPD Win 5 contains a 0x0-0x1 identity mapping for DMA
devices, causing it to be repeated for each device.

The cause of this failure is the following check in
iommu_create_device_direct_mappings(), where address aliasing is handled
via the following check:

```
phys_addr = iommu_iova_to_phys(domain, addr);
if (!phys_addr) {
        map_size += pg_size;
        continue;
}
````

Obviously, the iommu_iova_to_phys() signature is faulty and aliases
unmapped and 0 together, causing the allocation code to try to
re-allocate the 0 address per device. However, it has too many
instantiations to fix. Therefore, use a ternary so that when addr
is 0, the check is done for address 1 instead.

Suggested-by: Robin Murphy <robin.murphy@arm.com>
Fixes: 789a5913b29c ("iommu/amd: Use the generic iommu page table")
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>

---
V2: https://lore.kernel.org/all/20260226204400.15573-1-lkml@antheas.dev/
V1: https://lore.kernel.org/lkml/20260221235050.2558321-1-lkml@antheas.dev/

Changes since V2:
  - When addr is 0, check for address 1 instead. Add Suggested by for
    Robin. This is an alternate fix.

Changes since V1:
  - Remove closes tag. Turns out there are multiple compounding bugs.
    See [1]
  - Remove warn log
  - Remove the addr check and make skipping universal
  - Cleanup commit message

[1] https://github.com/CachyOS/linux-cachyos/issues/704
---
 drivers/iommu/iommu.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 2ca990dfbb88..3a0c0e4b42ff 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1207,7 +1207,11 @@ static int iommu_create_device_direct_mappings(struct iommu_domain *domain,
 			if (addr == end)
 				goto map_end;
 
-			phys_addr = iommu_iova_to_phys(domain, addr);
+			/*
+			 * Return address by iommu_iova_to_phys for 0 is
+			 * ambiguous. Offset to address 1 if addr is 0.
+			 */
+			phys_addr = iommu_iova_to_phys(domain, addr ? addr : 1);
 			if (!phys_addr) {
 				map_size += pg_size;
 				continue;

base-commit: f14faaf3a1fb3b9e4cf2e56269711fb85fba9458
-- 
2.52.0

Re: [PATCH v3] iommu: Fix mapping check for 0x0 to avoid re-mapping it

[Jason Gunthorpe]

On Fri, Feb 27, 2026 at 09:06:37AM +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.
> 
> Specifically, on the GPD Win 5, the NVME and SSD GPU fail to mount,
> making collecting errors difficult. While debugging, it was found that
> a -EADDRINUSE error was emitted and its source was traced to
> iommu_iova_to_phys(). After adding some debug prints, it was found that
> phys_addr becomes 0, which causes the code to try to re-map the 0
> address and fail, causing a cascade leading to a failed post. This is
> because the GPD Win 5 contains a 0x0-0x1 identity mapping for DMA
> devices, causing it to be repeated for each device.
> 
> The cause of this failure is the following check in
> iommu_create_device_direct_mappings(), where address aliasing is handled
> via the following check:
> 
> ```
> phys_addr = iommu_iova_to_phys(domain, addr);
> if (!phys_addr) {
>         map_size += pg_size;
>         continue;
> }
> ````
> 
> Obviously, the iommu_iova_to_phys() signature is faulty and aliases
> unmapped and 0 together, causing the allocation code to try to
> re-allocate the 0 address per device. However, it has too many
> instantiations to fix. Therefore, use a ternary so that when addr
> is 0, the check is done for address 1 instead.
> 
> Suggested-by: Robin Murphy <robin.murphy@arm.com>
> Fixes: 789a5913b29c ("iommu/amd: Use the generic iommu page table")
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> 
> ---

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH v3] iommu: Fix mapping check for 0x0 to avoid re-mapping it

[Antheas Kapenekakis]

On Fri, 27 Feb 2026 at 15:03, Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Fri, Feb 27, 2026 at 09:06:37AM +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.
> >
> > Specifically, on the GPD Win 5, the NVME and SSD GPU fail to mount,
> > making collecting errors difficult. While debugging, it was found that
> > a -EADDRINUSE error was emitted and its source was traced to
> > iommu_iova_to_phys(). After adding some debug prints, it was found that
> > phys_addr becomes 0, which causes the code to try to re-map the 0
> > address and fail, causing a cascade leading to a failed post. This is
> > because the GPD Win 5 contains a 0x0-0x1 identity mapping for DMA
> > devices, causing it to be repeated for each device.
> >
> > The cause of this failure is the following check in
> > iommu_create_device_direct_mappings(), where address aliasing is handled
> > via the following check:
> >
> > ```
> > phys_addr = iommu_iova_to_phys(domain, addr);
> > if (!phys_addr) {
> >         map_size += pg_size;
> >         continue;
> > }
> > ````
> >
> > Obviously, the iommu_iova_to_phys() signature is faulty and aliases
> > unmapped and 0 together, causing the allocation code to try to
> > re-allocate the 0 address per device. However, it has too many
> > instantiations to fix. Therefore, use a ternary so that when addr
> > is 0, the check is done for address 1 instead.
> >
> > Suggested-by: Robin Murphy <robin.murphy@arm.com>
> > Fixes: 789a5913b29c ("iommu/amd: Use the generic iommu page table")
> > Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> >
> > ---
>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Tested. It should be good to merge

Antheas

> Jason
>

Re: [PATCH v3] iommu: Fix mapping check for 0x0 to avoid re-mapping it

[Vasant Hegde]

On 2/27/2026 1:36 PM, 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.
> 
> Specifically, on the GPD Win 5, the NVME and SSD GPU fail to mount,
> making collecting errors difficult. While debugging, it was found that
> a -EADDRINUSE error was emitted and its source was traced to
> iommu_iova_to_phys(). After adding some debug prints, it was found that
> phys_addr becomes 0, which causes the code to try to re-map the 0
> address and fail, causing a cascade leading to a failed post. This is
> because the GPD Win 5 contains a 0x0-0x1 identity mapping for DMA
> devices, causing it to be repeated for each device.
> 
> The cause of this failure is the following check in
> iommu_create_device_direct_mappings(), where address aliasing is handled
> via the following check:
> 
> ```
> phys_addr = iommu_iova_to_phys(domain, addr);
> if (!phys_addr) {
>         map_size += pg_size;
>         continue;
> }
> ````
> 
> Obviously, the iommu_iova_to_phys() signature is faulty and aliases
> unmapped and 0 together, causing the allocation code to try to
> re-allocate the 0 address per device. However, it has too many
> instantiations to fix. Therefore, use a ternary so that when addr
> is 0, the check is done for address 1 instead.
> 
> Suggested-by: Robin Murphy <robin.murphy@arm.com>
> Fixes: 789a5913b29c ("iommu/amd: Use the generic iommu page table")
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>

Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>

-Vasant

Re: [PATCH v3] iommu: Fix mapping check for 0x0 to avoid re-mapping it

[Joerg Roedel]

On Fri, Feb 27, 2026 at 09:06:37AM +0100, Antheas Kapenekakis wrote:
> Suggested-by: Robin Murphy <robin.murphy@arm.com>
> Fixes: 789a5913b29c ("iommu/amd: Use the generic iommu page table")
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
> 
> ---
> V2: https://lore.kernel.org/all/20260226204400.15573-1-lkml@antheas.dev/
> V1: https://lore.kernel.org/lkml/20260221235050.2558321-1-lkml@antheas.dev/
> 
> Changes since V2:
>   - When addr is 0, check for address 1 instead. Add Suggested by for
>     Robin. This is an alternate fix.
> 
> Changes since V1:
>   - Remove closes tag. Turns out there are multiple compounding bugs.
>     See [1]
>   - Remove warn log
>   - Remove the addr check and make skipping universal
>   - Cleanup commit message
> 
> [1] https://github.com/CachyOS/linux-cachyos/issues/704
> ---
>  drivers/iommu/iommu.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Applied, thanks