strongtz/i915-sriov-dkms: Intel iGPU SR-IOV for Proxmox Hosts and Their VMs

The problem: one Intel iGPU, several VMs that each want a GPU

A single Intel integrated GPU is normally claimed by one kernel driver and handed to one consumer. Splitting it between virtual machines has traditionally meant either buying a second card or accepting software rendering inside the guest. SR-IOV changes that by letting a PCI device advertise virtual functions that can each be assigned to a separate guest, with the physical function staying on the host.

The mainline i915 driver does not carry that support. This repository is a snapshot of the i915 and xe modules taken from the mainline kernel, with SR-IOV support ported from Intel's mainline-tracking tree. The README states that the module must be installed on both the host and the guest, which is unusual: the guest is not running a stock driver but the same out-of-tree build.

The audience is narrow on purpose. The README opens with a warning that the package is highly experimental and should only be used by people who know what they are doing, and a disclaimer that the project is a community effort with no affiliation to Intel. If you want a graphics stack you can file a support ticket against, this is not it.

How the DKMS build and the two drivers fit together

The repository ships both drivers and lets you pick one at boot. The Makefile builds three module groups: compat/, drivers/gpu/drm/i915/ and drivers/gpu/drm/xe/. It also vendors its own copy of the GPUSVM module through CONFIG_DRM_GPUSVM := y, so the tree is not a thin patch over your distribution's kernel headers.

Kernel compatibility is handled by a conftest step. The Makefile defines CONFTEST_COMPILE_TESTS with entries such as copy_from_user_inatomic_nontemporal, drm_exec_for_each_locked_object_no_index and pci_resize_resource_4args, and runs conftest.sh compile_test for each one when the generated conftest/results.h is missing. That header is then force-included into the build. The practical effect is that the same source tree can build against kernels with slightly different internal APIs, which is what makes a DKMS module spanning a kernel range feasible at all.

The version is stamped into the build through DKMS_MODULE_VERSION := "2026.09.16-sriov" and DKMS_MODULE_ORIGIN_KERNEL := "7.2.0". The README notes that host and guest are not strictly required to run the same module version, which gives some room when you upgrade one side before the other.

Driver selection is a kernel-parameter decision, not a build option. The i915 line is intel_iommu=on i915.enable_guc=3 i915.max_vfs=7 module_blacklist=xe. The xe line is intel_iommu=on xe.max_vfs=7 xe.force_probe=${device_id} module_blacklist=i915, where the README says to substitute the output of cat /sys/devices/pci0000:00/0000:00:02.0/device. Each line blacklists the other driver, so the two cannot be loaded together.

Installing on a Proxmox host and creating the first VF

The README does not inline installation steps. It points to per-distribution guides under docs/: install-pve-host.md for Proxmox, install-arch-host.md for Arch, install-nixos-host.md for NixOS, and install-manual.md for Debian, Ubuntu and Arch hosts. Guest guides cover Ubuntu, an Ubuntu 25.04 Cloud-Init VM on Proxmox, and Windows 11 24H2 tested with Proxmox 8.3. Start with the guide matching your host, because the kernel-parameter and repository setup differs between them.

Before any of that, check the kernel. The README states the required kernel is 6.18.x to 7.2.x. For older kernels it directs you elsewhere: the 2026.03.05.7 release for v6.12 to v6.19, the 2025.07.22 release for v6.8 to v6.12, and the intel-lts-v6.1 branch for v6.1 to v6.7. The README adds that older branches will no longer be maintained and recommends upgrading to a supported kernel.

Secure Boot has to be off, or the module has to be signed. The README states that loading out-of-tree kernel modules requires Secure Boot to be disabled, and points to docs/secure-boot.md for signing instructions on Ubuntu, Proxmox VE and Debian-based distributions.

Once the module is loaded, creating virtual functions is a single write. The README gives this example, which allocates seven VFs on the graphics device:

echo 7 > /sys/devices/pci0000:00/0000:00:02.0/sriov_numvfs

After that, the VFs appear as functions 00:02.1 through 00:02.7. The README says you can passthrough any of those to a VM, and warns in the same breath never to pass the PF (listed there as 02:00.0) to a VM, because doing so crashes all the other VFs. For containers and LXCs the advice is different: pass through the render node of the PF directly rather than a VF.

There is an optional step for hosts that should not expose the VFs to the host itself, documented in docs/block-vfs.md and applicable to Arch, Ubuntu and Proxmox VE.

Meteor Lake, Lunar Lake and the CCS0 change on Xe_LP

Two platform constraints are worth reading before you commit to a driver choice. The README states that the xe module does not support MTL (Meteor Lake) or LNL (Lunar Lake), and tells those users to use i915 instead. That single sentence decides the driver for a whole generation of laptops and mini PCs.

The second constraint arrived with release 2026.09.16. On Xe_LP platforms (TGL, ADL, RPL), CCS0 is no longer enabled by default. The README ties this to Windows guest VMs: if you hit problems there, you append i915.xelp_enable_ccs=1 for the i915 driver or xe.xelp_enable_ccs=1 for the xe driver to the kernel command line. Anyone upgrading from an earlier release onto one of those platforms should expect this to matter, because the default changed underneath them.

This is the shape of the project's risk. A parameter that used to be implicit became explicit, and the symptom shows up as a guest misbehaving rather than as a build error. Release notes are the only place that records it.

Recovering a host that will not boot after the module loads

The README has a troubleshooting section that assumes the failure mode is a hang or a black screen at boot. The recovery is to blacklist the modules from the bootloader for one boot.

Under GRUB2: at the boot menu, select the kernel, press e, find the line starting with linux, append module_blacklist=i915,xe preceded by a space, then press F10 or Ctrl+X to boot. Under systemd-boot: press e at the menu, append the same string to the existing line, then press Enter.

That gets you a running system. The README then suggests inspecting kernel logs, and says that if the module remains unstable you should follow the uninstallation steps in your distribution's installation guide. Note what is missing: the README does not document rollback of a kernel-parameter change, and it does not describe what a partially working state looks like. You are expected to read logs and decide.

The blast radius is the part to weigh. Because the module replaces the graphics driver on the host, a bad build can take the host's own display with it, not just the guests. A machine you administer over SSH is a much better candidate than a workstation you sit in front of.

i915 versus xe, and what a stock kernel gives you instead

The real alternative is not another project. It is the driver your distribution already ships. A stock kernel gives you a supported i915 or xe module, no DKMS rebuilds on every kernel update, and Secure Boot left enabled. What it does not give you is SR-IOV, so a VM gets no hardware-accelerated Intel graphics. That is the entire trade: you accept an out-of-tree module and its maintenance burden in exchange for VF passthrough.

Within the project, i915 and xe are two different answers to the same question. i915 is the older driver and, per the README, the one to use on Meteor Lake and Lunar Lake. xe is the newer driver, requires xe.force_probe with the device ID read from sysfs, and does not support those two platforms. The README also notes that the repository now provides both, which means the choice is yours to make at the kernel command line rather than something the package decides.

If your goal is simply to run a Linux guest with a working desktop, and you do not need GPU passthrough, none of this is worth the risk. The project's own warning language points the same way.

Maintenance burden, upgrade path and licence

The last push to the repository was on 2026-09-27, and the most recent release is 2026.09.16, published on 2026-09-16. The repository is not archived. Releases are dated rather than numbered in a semantic sense, so 2026.09.16 supersedes 2026.09.14, and 2026.03.05.7 remains the recommended release for kernels v6.12 to v6.19.

The upgrade cost is real and predictable. A DKMS module rebuilds against each new kernel, so a kernel bump on the host is a rebuild event. The conftest machinery in the Makefile exists to absorb API drift across the supported kernel range, but the README's own version table shows that support is a moving window: 6.18.x to 7.2.x for the current release, with older kernels pushed to older releases or to the intel-lts-v6.1 branch, and a statement that older branches will no longer be maintained. Plan to move your kernel forward, not to sit on one.

The licence is GPL-2.0, with COPYING at the top level of the repository. That is the same licence family as the Linux kernel, which is what makes distributing a derived kernel module coherent. It does not change the fact that this is a community port with an explicit disclaimer of any connection to Intel. If you redistribute the module, or ship it in a product image, the licence terms and the signing requirements in docs/secure-boot.md are the two things to read. This is not legal advice.

Editorial conclusion

Adopt it if you run a Proxmox or Arch host on a kernel inside the 6.18.x to 7.2.x window, you are willing to disable Secure Boot, and you accept that the project calls itself highly experimental. Do not adopt it if you need a supported configuration, if your kernel is older, or if you cannot tolerate a boot hang that requires editing the kernel command line from the boot menu to recover. Before installing, verify three things: the kernel version you are actually running, the output of cat /sys/devices/pci0000:00/0000:00:02.0/device if you intend to use the xe driver with xe.force_probe, and whether your platform is Meteor Lake or Lunar Lake, in which case the README directs you to i915 because xe does not support those chips.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. strongtz/i915-sriov-dkms on GitHub