[BUG][AMD IOMMU][VFIO] IVMD exclusion ranges block GPU passthrough on ASUS GA403UI, reproduced on 7.4-rc0

[BUG][AMD IOMMU][VFIO] IVMD exclusion ranges block GPU passthrough on ASUS GA403UI, reproduced on 7.4-rc0

[César Zapata]

 
Hello,
I would like to report a reproducible AMD IOMMU/VFIO issue on an ASUS ROG Zephyrus G14 GA403UI, now confirmed using an upstream Linux Mainline Vanilla 7.4.0-rc0 kernel without the proprietary NVIDIA driver.

The firmware publishes broad IVMD exclusion ranges that Linux exposes as IOMMU_RESV_DIRECT. Consequently, VFIO refuses to establish an IOMMU domain for an otherwise isolated NVIDIA GPU.

System information
System: ASUS ROG Zephyrus G14 GA403UI_GA403UI
CPU: AMD Ryzen 9 8945HS
BIOS: GA403UI.311, 06/09/2025
Distribution: Fedora 44 Workstation
Virtualization: QEMU/KVM with libvirt 12.0.0
AMD-Vi: Enabled and operational

Kernels tested
Fedora 7.2.8-200.fc44.x86_64 — VFIO failure reproduced
Fedora 7.2.11-200.fc44.x86_64 — IOMMU_RESV_DIRECT persists
Stable Vanilla 7.3.0-363.vanilla.fc44.x86_64 — IOMMU_RESV_DIRECT persists
Mainline Vanilla 7.4.0-0.rc0.261022.7be4bc52.302.vanilla.fc44.x86_64 — VFIO failure fully reproduced

The Mainline test used the in-tree nouveau driver, not the proprietary NVIDIA driver.

PCI devices and IOMMU group
The devices being assigned are:
0000:01:00.0 [10de:2860] NVIDIA AD106M / GeForce RTX 4070 Laptop GPU
0000:01:00.1 [10de:22bd] NVIDIA High Definition Audio Controller
Both functions are isolated in IOMMU group 14, with no unrelated devices.
The internal display is driven by the AMD iGPU (65:00.0), allowing the graphical session to be stopped without disabling the host display hardware.

Reserved regions
On Mainline 7.4.0-rc0:
$ cat /sys/kernel/iommu_groups/14/reserved_regions

0x0000000097d36000 0x0000000097d37fff direct
0x00000000fee00000 0x00000000feefffff msi
0x000000fd00000000 0x000000ffffffffff reserved
The same direct region is exposed for many other IOMMU groups, including groups 0 through 17.
ACPI IVRS / IVMD

The firmware IVRS table contains two IVMD type 0x22 entries with exclusion flag 0x08, covering requester IDs 0x0000–0x0fff.
Their memory ranges are:
0x97d36000–0x97d36fff
0x97d37000–0x97d37fff
Relevant raw IVRS bytes:
00C0: 48 00 00 00 22 01 00 01 22 08 20 00 00 00 FF 0F
00D0: 00 00 00 00 00 00 00 00 00 70 D3 97 00 00 00 00
00E0: 01 00 00 00 00 00 00 00 22 08 20 00 00 00 FF 0F
00F0: 00 00 00 00 00 00 00 00 00 60 D3 97 00 00 00 00
0100: 01 00 00 00 00 00 00 00
These exclusion entries appear to be responsible for the IOMMU_RESV_DIRECT region affecting the GPU.

Reproduction on upstream Mainline 7.4.0-rc0
Boot the Mainline Vanilla kernel.
Confirm that 01:00.0 uses nouveau and 01:00.1 uses snd_hda_intel.
Connect to the host via SSH.
Stop GDM and verify that no users remain on the DRM devices.
Start an existing Windows 11 QEMU/KVM guest using both PCI functions with libvirt managed='yes'.
The GPU is successfully rebound to vfio-pci during VM startup.

However, VFIO reports:
vfio-pci 0000:01:00.0: Firmware has requested this device have a 1:1 IOMMU mapping, rejecting configuring the device without a 1:1 mapping. Contact your platform vendor.
The VM fails to start.
Libvirt subsequently rolls back the assignment and restores:
01:00.0 -> nouveau
01:00.1 -> snd_hda_intel

This demonstrates that PCI driver binding and unbinding work, but VFIO cannot establish the required IOMMU domain.

The same kernel error was previously reproduced on Fedora 7.2.8 with the proprietary NVIDIA driver, followed by successful rollback to the NVIDIA host driver.

No ACS override, allow_unsafe_interrupts, vfio-pci.ids=, IOMMU bypass parameters, or local kernel patches were used.

Related upstream work
This appears closely related to the AMD IOMMU IVMD handling series:
[PATCH v2 0/4] iommu/amd: IVMD handling cleanup and ivmd= boot override
https://lore.kernel.org/all/20260424092213.16976-1-suravee.suthikulpanit@amd.com/

In particular, the proposed change to avoid converting IVMD exclusion regions into mandatory unity mappings appears relevant to this system.

A separate test report from October 1, 2026, also describes broad IVMD exclusion ranges and their conversion from direct to reserved after applying the v2 series:
https://lists.openwall.net/linux-kernel/2026/10/01/120

I have not yet applied that patch series to this system, and I cannot confirm whether it resolves the full VFIO assignment failure here.
Fedora bug report https://bugzilla.redhat.com/show_bug.cgi?id=2559096
The Fedora report has been updated with the full Mainline 7.4.0-rc0 reproduction and kernel log.

Available diagnostic information
I can provide:
Complete ACPI IVRS table (ivrs.dat)
Decoded IVRS table (ivrs.dsl)
Complete kernel log from the Mainline 7.4.0-rc0 failure (attached)
lspci -nnk output
IOMMU group topology
Reserved regions from all groups
Relevant libvirt domain XML

I am willing to test an updated AMD IOMMU patch series or a diagnostic kernel build, and report the resulting reserved regions, VFIO assignment behavior, and host recovery.

Could you confirm whether the current AMD IVMD handling work is expected to address this case, or whether additional firmware/platform diagnostics would be useful?

Regards

César Z.