intel-igpu-passthru: the ROM files behind working Intel iGPU passthrough

The deliverable is a set of OpROM files, not a patch or a driver

intel-igpu-passthru is a repository of OpROM/VBIOS images for GVT-d iGPU passthrough on Proxmox, QEMU and KVM. That distinction sets expectations correctly. There is no agent to install, no kernel module to compile and no configuration file format to learn beyond pointing a virtual machine at a ROM. What the project provides is the missing piece of firmware for Intel integrated graphics generations that are too new to be handled by the generic path.

The problem it addresses is concrete and familiar to anyone who has tried GVT-d. The guest takes the iGPU, the guest driver initialises, and the screen works, but Windows reports Code 43 and disables the device, or the display comes up distorted or only after the guest driver is fully loaded. The firmware shipped in the host BIOS carries the Intel GOP driver for the generation, and passing that firmware into the guest is what makes the output appear as if the graphics hardware had never moved. The project describes its goal as direct UEFI display output over HDMI, eDP, DVI and DisplayPort, and it states that the result works with Windows, Linux and even macOS guests. For macOS there is a separate file, macOS_README.md, because that guest needs extra configuration beyond the common path.

One ROM per Intel generation, matched through a GOP version table

The core of the project is a table mapping Intel CPU generations to ROM files and GOP versions. Sandy Bridge 2nd gen pairs with a v2 ROM, Ivy Bridge with v3, Haswell and Broadwell with v5, Skylake through Comet Lake with v9, and Coffee Lake and Comet Lake with v9.1. Mobile parts get their own entries: Ice Lake 10th gen mobile has a v14 file, Rocket, Tiger, Alder and Raptor Lake share v17 and v17.1 variants, and low-end parts such as Gemini Lake and Jasper Lake have their own v13 and v18 files.

The table also covers the cases that break a naive approach. Alder Lake-H, Raptor Lake-H and the P and U series have a v21 entry, Alder Lake-N and Twin Lake have a separate v21 file for N95, N97 and N1xx to N3xx machines, Arrow Lake and Meteor Lake share a v22 file, Lunar Lake has its own file, and Panther Lake-H has a v22-era entry too. GOP version is the meaningful column here, since it tracks how new the graphics firmware is. Lunar Lake and Panther Lake-H are listed with an unknown GOP version, which is worth noticing since it removes one of the signals you might normally use to confirm a match. The repository also ships a helper script, pve_rebind_pci.sh, alongside the README and the macOS notes.

Fetching the ROM into /usr/share/kvm is a two step job

The install path is short, and it is the clearest part of the workflow. First pick the ROM file for your CPU from the table, open its release link, right click and copy the link address. Then open a Proxmox VE shell and download it to the path QEMU reads ROM files from, naming it igd.rom so the VM configuration has one stable name to point at. The README gives the download as a single curl invocation, where the placeholder is the link you just copied:

curl -L <ROM_URL> -o /usr/share/kvm/igd.rom

After that, point the virtual machine at the file. The README lists two Proxmox configuration paths, Legacy Mode and UPT Mode, under a heading that explains the mode determines how display outputs are handled, and it also covers other Linux distributions running QEMU and KVM directly. Two details of the surrounding setup matter as much as the download. The guest should use OVMF firmware rather than the legacy BIOS path, and for a headless machine the guest operating system needs to be installed already with remote access such as RDP or VNC configured, because the display you are working toward is not the way in. The release page also publishes sha256sum values, so the download can be checked against the published hash before a VM is pointed at it.

The Universal_noGOP fallback trades early output for a working guest

One row of the table is different from the rest. Universal_noGOP_igd.rom is listed for all Intel CPUs with an iGPU, and the README is explicit that it should be used as a last resort if other ROMs cause issues. The reason is in the name and in the note attached to it: the Universal ROM does not include the Intel GOP driver.

Without the GOP driver, the UEFI Graphics Output Protocol is missing, so display output only works once the guest VM drivers have fully loaded. That is a different experience from the per-generation ROMs, where the picture appears early and stays undistorted. It also means a Universal ROM will not fix the case where the guest has no working display driver at all, and it does nothing for the Code 43 problem the project exists to solve. The practical reading is that the Universal file is a way to keep a VM usable when you have a machine the table does not cover, not a shortcut to the same result. If your CPU has a named row, take that row.

The BIOS settings are not optional, and disable_vga=1 breaks the setup

The requirements section of the README lists what has to be true on the host before any of this works. You need an Intel CPU with integrated graphics, second generation or newer. The BIOS must boot in UEFI-only mode with Legacy and CSM disabled, the VGA OpROM must be set to UEFI, Intel VT-d has to be enabled, and the initial or primary graphics adapter must be set to IGD, iGPU or integrated. On the host operating system side, Proxmox VE 9.1 or newer or a modern Linux distribution with kernel 6.8 or newer, with IOMMU enabled, is required, and IOMMU is on by default in Proxmox VE 8.2 and newer.

There is one setting that silently breaks the whole arrangement. The README marks it important twice over: disable_vga=1 must not be set anywhere in /etc/modprobe.d/vfio.conf or in your kernel parameters in /etc/default/grub. The reason it matters is the purpose of that option. Disabling the VGA device is what a standard passthrough recipe does to stop the host from touching the graphics hardware, and on a GVT-d setup it takes away the very firmware path the guest is meant to inherit. The fix is to remove the option, then run update-grub, update-initramfs -u and reboot. An optional item in the same list is that blacklisting i915 may be required to reach the maximum supported resolution and refresh rate, which makes the display result a tuning matter rather than a binary outcome.

Meteor Lake, Arrow Lake and Lunar Lake need QEMU 10.1 or newer

Newer silicon has its own gate, and it is a version gate rather than a settings gate. The README states that Meteor Lake, Arrow Lake, Lunar Lake and future Intel iGPUs require QEMU 10.1 or newer, and it points at the kvm --version command for checking. That command is a diagnostic in the strict sense: it tells you the QEMU version you have, and against that number you decide whether the ROM you downloaded can even be loaded by the virtual machine.

This matters for anyone reading the ROM table first, because the table covers the newest parts. A v22 ROM for Arrow Lake and Meteor Lake, a dedicated file for Lunar Lake, and a Panther Lake-H entry all sit in the same list as the v2 file for Sandy Bridge from fifteen years earlier. The presence of a ROM file for a generation says nothing about whether your toolchain can use it. The requirement list also names kernel 6.8 or newer for modern Linux hosts and Proxmox VE 9.1 or newer, so the older Proxmox 8.x path implied by the 8.2 IOMMU note is not the path to follow for the newest CPUs. The practical sequence is to check the QEMU version first, then pick the ROM, rather than the other way around.

SR-IOV virtual functions are a second route to fixing Code 43

The Code 43 problem has more than one solution in this project, and the second is not the OpROM. The overview lists two separate items: fixing Code 43 errors in Windows guests with iGPU passthrough, and staying compatible with SR-IOV virtual functions to fix the same Code 43 errors. The repository topics make the same pairing explicit with gvt-d, gvt-g, i915-sriov, igd, legacy-igd, pci-passthrough, vfio and vfio-pci.

The distinction is in what the guest receives. A direct GVT-d arrangement hands the guest the whole iGPU, and the ROM work is what makes that arrangement display correctly. An SR-IOV arrangement hands out virtual functions, and the guest driver sees a function rather than the physical device, which changes the Code 43 story without needing the same firmware path. The README does not walk through the SR-IOV configuration in the sections reproduced here, so treat the compatibility claim as a direction to investigate rather than a procedure to copy. The repository does include pve_rebind_pci.sh at the top level, which is the kind of helper used when the host binding of a PCI function has to be moved between the host and the guest.

One release, an open licence, and a last push in June 2026

The maintenance picture is small and easy to state. The project has a single GitHub release, v0.1, published on 2025-09-30 and titled ROM Files and Hashes, and every ROM in the table is served from that one release. The last push to the repository was on 2026-06-04, and the repository is not archived. There is no changelog beyond that release entry, so the release page is the place to check whether a ROM for a new Intel generation has appeared.

The licence is BSD-2-Clause, which is a permissive licence with a short notice requirement, and the ROM binaries themselves are distributed as release assets under it. That is worth understanding as a redistribution question rather than a legal opinion, in particular if you plan to mirror the ROM files internally. The README also collects credits and acknowledgements for the underlying Intel firmware work, which matters because the ROMs are derived from vendor firmware rather than written from scratch. Bug reports, feature requests and the wider documentation live in the repository's GitHub configuration directory, and the README points to additional documentation beyond the reproduction steps shown here.

Editorial conclusion

Use intel-igpu-passthru if your host is an Intel CPU with integrated graphics and you want a guest to own the physical screen through GVT-d, and pick the ROM whose row matches your generation rather than the Universal fallback. Do not use it for an AMD or discrete-only NVIDIA setup, on a host still booting in Legacy/CSM mode, or for Meteor Lake, Arrow Lake or Lunar Lake unless your QEMU is 10.1 or newer. Before you start, check three things: that `disable_vga=1` is absent from `/etc/modprobe.d/vfio.conf` and from `/etc/default/grub`, that the VGA OpROM in your BIOS is set to UEFI with IGD as the primary adapter, and that the sha256sum for your ROM on the release page matches what you downloaded. With a matching ROM in `/usr/share/kvm/igd.rom` and OVMF firmware in the guest, the display path is the part this project actually fixes.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. LongQT-sea/intel-igpu-passthru on GitHub
4. README
5. Releases