Fedora Account System
Red Hat Associate
Red Hat Customer
1. Please describe the problem: On an ASUS ROG Zephyrus G14 GA403UI with an AMD Ryzen 9 8945HS, AMD IOMMU IVMD exclusion ranges are exposed by Linux as IOMMU_RESV_DIRECT regions. This prevents VFIO from assigning an otherwise properly isolated NVIDIA RTX 4070 Laptop GPU to a QEMU/KVM guest. Hardware: ASUS ROG Zephyrus G14 GA403UI_GA403UI BIOS: GA403UI.311, release date 06/09/2025 CPU: AMD Ryzen 9 8945HS Discrete GPU: 01:00.0 [10de:2860] NVIDIA AD106M [GeForce RTX 4070 Max-Q / Mobile] GPU audio: 01:00.1 [10de:22bd] NVIDIA AD106M High Definition Audio Controller Integrated GPU: 65:00.0 [1002:1900] AMD HawkPoint1 AMD-Vi is enabled and operational. The NVIDIA GPU and its audio function are isolated together in IOMMU group 14, with no unrelated devices. For IOMMU group 14: $ cat /sys/kernel/iommu_groups/14/reserved_regions 0x0000000097d36000 0x0000000097d37fff direct 0x00000000fee00000 0x00000000feefffff msi 0x000000fd00000000 0x000000ffffffffff reserved The same 0x97d36000-0x97d37fff direct region is exposed for many other IOMMU groups on this system. The ACPI IVRS table contains two IVMD type 0x22 entries corresponding to adjacent 4 KiB regions at: 0x97d36000 0x97d37000 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 The GPU can be detached successfully from its normal host drivers and bound to vfio-pci: 01:00.0: nvidia -> vfio-pci 01:00.1: snd_hda_intel -> vfio-pci Manual reattach also works correctly. However, when QEMU/VFIO attempts to use the IOMMU group, the kernel 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. QEMU/libvirt then fails with: vfio 0000:01:00.0: failed to setup container for group 14: Failed to set group container: Invalid argument After the VM start fails, libvirt correctly rolls the devices back to: 01:00.0 -> nvidia 01:00.1 -> snd_hda_intel Therefore, PCI detach/bind itself works. The failure occurs when VFIO attempts to establish ownership/DMA mapping for the IOMMU group. No ACS override, allow_unsafe_interrupts, vfio-pci.ids=, or other IOMMU bypass/workaround is being used. 2. What is the Version-Release number of the kernel: Current kernel: 7.2.11-200.fc44.x86_64 $ uname -a Linux fedora 7.2.11-200.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Oct 15 15:58:58 UTC 2026 x86_64 GNU/Linux 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : No known working Fedora kernel. The issue was reproduced with: 7.2.8-200.fc44.x86_64 7.2.11-200.fc44.x86_64 With both kernels, /sys/kernel/iommu_groups/14/reserved_regions contains: 0x0000000097d36000 0x0000000097d37fff direct and VFIO fails when QEMU attempts to use the GPU group. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Yes, it is reproducible. 1. Boot Fedora 44 normally with AMD-Vi enabled. 2. Verify that the NVIDIA GPU and audio function are isolated in IOMMU group 14: 01:00.0 NVIDIA RTX 4070 Laptop GPU 01:00.1 NVIDIA HD Audio 3. Verify the reserved region: cat /sys/kernel/iommu_groups/14/reserved_regions The output includes: 0x0000000097d36000 0x0000000097d37fff direct 4. Stop users of the NVIDIA GPU: sudo systemctl stop gdm sudo systemctl stop nvidia-powerd.service Verify that: sudo fuser -v /dev/nvidia* shows no remaining users. 5. Start a libvirt VM configured with both NVIDIA PCI functions as managed host devices: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> </source> </hostdev> 6. Start the VM: virsh -c qemu:///system start Win11 The GPU is detached and bound to vfio-pci, but VM startup fails. 7. Kernel log contains: 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. 8. QEMU/libvirt reports: vfio 0000:01:00.0: failed to setup container for group 14: Failed to set group container: Invalid argument 9. Libvirt then rolls the devices back successfully to nvidia and snd_hda_intel. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Not tested with the latest Rawhide kernel. I have reproduced the issue with Fedora 44 kernels 7.2.8-200.fc44.x86_64 and 7.2.11-200.fc44.x86_64. I can test a Rawhide kernel or a proposed AMD IOMMU patch if requested. 6. Are you running any modules that not shipped with directly Fedora's kernel?: Yes. The proprietary NVIDIA kernel modules from RPM Fusion are installed through akmods: akmod-nvidia-615.71.09-3.fc44.x86_64 For the currently running kernel: kmod-nvidia-7.2.11-200.fc44.x86_64-615.71.09-3.fc44.x86_64 The NVIDIA modules are used normally by the host, but the VFIO failure occurs after the GPU has been successfully detached from the NVIDIA driver and bound to vfio-pci. No out-of-tree IOMMU or VFIO modules are installed. 7. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. The issue was reproduced again on the current boot with kernel: 7.2.11-200.fc44.x86_64 Immediately after reproducing the VFIO failure I collected: - complete kernel log: dmesg-vfio.txt - filtered libvirt/QEMU/VFIO journal: vfio-libvirt-filtered.txt - virtqemud journal: virtqemud-vfio.txt The reproduced QEMU/libvirt failure was: vfio 0000:01:00.0: failed to setup container for group 14: Failed to set group container: Invalid argument The host recovered correctly after the failed VM start: 01:00.0 -> nvidia 01:00.1 -> snd_hda_intel and nvidia-smi worked normally again. I can also provide, if useful: - complete ACPI IVRS dump - decoded ivrs.dsl - full lspci -nnk output - full IOMMU group topology - reserved_regions output for all groups - libvirt domain XML Reproducible: Always
Created attachment 2161953 [details] Full kernel log from boot reproducing the VFIO failure Collected immediately after reproducing the VFIO passthrough failure on kernel 7.2.11-200.fc44.x86_64.
Created attachment 2161954 [details] Decoded ACPI IVRS table from affected system Decoded ACPI IVRS table from ASUS GA403UI BIOS GA403UI.311. Contains the IVMD type 0x22 entries associated with the 0x97D36000 and 0x97D37000 regions.
Created attachment 2161955 [details] Filtered libvirt/QEMU/VFIO journal from reproduction Filtered journal containing the QEMU/libvirt/VFIO messages from the same reproduction attempt
Created attachment 2161956 [details] virtqemud journal from VFIO reproduction virtqemud journal collected from the same boot and reproduction attempt.
Created attachment 2161957 [details] Raw ACPI IVRS table from affected system Raw ACPI IVRS table corresponding to the decoded ivrs.dsl attachment.
**Additional reproduction on upstream Linux Mainline 7.4.0-rc0** I have now reproduced the complete VFIO failure using an upstream Linux Mainline Vanilla kernel: `7.4.0-0.rc0.261022.7be4bc52.302.vanilla.fc44.x86_64` This test was performed without the proprietary NVIDIA driver. The host GPU was driven by the in-tree `nouveau` driver. The IOMMU group 14 still exposes: ```text 0x0000000097d36000 0x0000000097d37fff direct 0x00000000fee00000 0x00000000feefffff msi 0x000000fd00000000 0x000000ffffffffff reserved ``` After stopping GDM and confirming that no processes were using the DRM devices, I attempted to start the existing Windows 11 VM with both NVIDIA PCI functions configured as `managed='yes'`. The kernel reported: ```text 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 failed to start. Libvirt subsequently restored both devices to their original host drivers: ```text 01:00.0 -> nouveau 01:00.1 -> snd_hda_intel ``` This confirms that the issue is reproducible on an upstream Mainline Vanilla kernel and does not depend on the proprietary NVIDIA kernel driver. I have preserved the full kernel log from this reproduction and can test an AMD IOMMU/IVMD patch if provided.
Created attachment 2161964 [details] Full kernel log — VFIO failure reproduced on upstream Linux Mainline 7.4.0-rc0 Complete kernel log captured during a VFIO passthrough failure on Linux Mainline Vanilla 7.4.0-rc0 (7.4.0-0.rc0.261022.7be4bc52.302.vanilla.fc44.x86_64). The test used the in-tree nouveau driver instead of the proprietary NVIDIA driver. At 14:15:35, the kernel rejected VFIO assignment of PCI device 0000:01:00.0 because the firmware requires a 1:1 IOMMU mapping. The VM failed to start, and libvirt successfully restored the GPU and audio functions to their original host drivers. This reproduces the same failure previously observed on Fedora kernels 7.2.8 and 7.2.11, confirming that the issue also affects upstream Mainline.