May 19May 19 I understand that much. Perhaps I didn't express myself clearly. It's just that in version 7.3.0, a new feature was added allowing you to change the number of VFs under "PCI Devices and IOMMU Groups" as well. Now there are two places where I can modify these settings:Settings --> Intel Graphics SR-IOVDo you see what I mean now?
May 22May 22 After updating to 7.3.0, I found that the virtual graphics card generated by SR IoV can be used for Windows 11, but cannot be used for FNOS. Now I have rolled back to 7.2.4
May 22May 22 will this work now on 7.3 with i5 14500 ?if i passtrough it to my windows guest, i can install the intel display driver, devicemanager shows all ok, but parsec still uses software renderer and can run furmark etc.edit:ok, worked, but my whole igpu crashs after VM shutdown .. need to do : echo 1 > /sys/bus/pci/rescanin unraid shell + add VFs back (no restart nessesary , worked again after)but after each VM reboot / shutdown, the igpu crashs and i need rescan and readd the VFs, any solution for this? Edited May 22May 22 by Encore
June 11Jun 11 Hi, kinda noob and everything is working but I just wanted to ask about the version. I installed the plugin from unraid CA and the version is 2023.11.22 and that shows as up-to-date, but the github itself has versions newer than that. How come this is the case?
June 11Jun 11 1 hour ago, hoeman said:Hi, kinda noob and everything is working but I just wanted to ask about the version. I installed the plugin from unraid CA and the version is 2023.11.22 and that shows as up-to-date, but the github itself has versions newer than that. How come this is the case?im not sure where you looked but its certainly 2023.11.22https://raw.githubusercontent.com/giganode/unraid-i915-sriov/refs/heads/master/i915-sriov.plg
July 1Jul 1 Hi, I'm not sure if this is the right place but I'm wondering if someone can either explain or direct me to a page that explains how to get SR-IOV working with the Intel 285k iGPU to pass a VF through to a VM.I've looked around but the information is conflicting, am I supposed to use the Xe driver or can I still use i915? Am I still supposed to use this plugin as well? Is it even possible right now (the posts seemed to imply the kernel would support it early 2026 but haven't heard anything since). Any help with the latest info on this would be greatly appreciated.
July 6Jul 6 I have never been successful at getting a linux guest to successfully pass through a VF.I am trying again, because I really need access to the i915 graphics to run frigate.using cachyos (arch) as a guest... and tried a few things to get it going... but errors out like this:If you've managed to overcome something similar I would appreciate some steps to try. googling has not really helped me.I am running latest unraid... with sriov plugin installed and working. Win11 VM is able to work with this... but linux guests must have a secret sauce I am not aware of....>2026-07-06T10:43:13.649353Z qemu-system-x86_64: warning: vfio_container_dma_map(0x151aa730be00, 0x382820000000, 0x108000, 0x151a9f000000) = -22 (Invalid argument)0000:00:02.1: PCI peer-to-peer transactions on BARs are not supported.>
July 6Jul 6 @bucky2780 the sr-iov dkms module must be installed on Unraid and inside the guest. In addition all the apps in the guest(think the desktop environment, Plex, jellyfin, frigate) must run as a user with permission to access the gpu. This is not always the case and you must always check that the dkms module is installed and running without errors on the host (Unraid) and the guest and the relevant users have permission to use the gpu in the guest. It took me months to figure out those two things for Linux guests, windows just works out the box
July 6Jul 6 ok interesting... I don't mind spending months trying to get this to work....but on a recent cachyos vm install... here is what I get when I add a vf as graphics device....I did install dkms on the guest... though I'm surprised that would be needed.mystery abounds...[ 5.144395] i915 0000:06:00.0: [drm] Found alderlake_s/raptorlake_s (device ID a780) integrated display version 12.00 stepping D0 [ 5.226777] intel_rapl_msr: PL4 support detected (updated). [ 5.315093] systemd-journald[258]: Received client request to flush runtime journal. [ 7.146092] i915 0000:06:00.0: [drm] ERROR Device is non-operational; MMIO access returns 0xFFFFFFFF! [ 7.146399] i915 0000:06:00.0: [drm] ERROR Device initialization failed (-5) [ 7.146402] i915 0000:06:00.0: probe with driver i915 failed with error -5
July 10Jul 10 I recently installed/uninstalled the sr-iov plugin... to ensure it works as it is supposed to...I do get these worrying error messages every time I reboot unraid... particularly the segfault in igpu_top is a little worrying.The plugin does seem to work... but my system is a litlte unstable... What do you think about these error messages ? Benign or not ?>>Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] ERROR GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF1 state (-EPROTO)Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] ERROR GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF2 state (-EPROTO)Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] ERROR GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE000000AJul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF3 state (-EPROTO)Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] ERROR GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE000000AJul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF4 state (-EPROTO)Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] ERROR GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE000000AJul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF5 state (-EPROTO)Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] ERROR GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE000000AJul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF6 state (-EPROTO)Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] ERROR GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE000000AJul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF7 state (-EPROTO)Jul 11 05:57:02 buckyu kernel: intel_gpu_top[36393]: segfault at 78 ip 000055919e3d1464 sp 00007ffc43596790 error 4 in intel_gpu_top[9464,55919e3ce000+a000] likely on CPU 12 (core 24, socket 0)Jul 11 05:57:02 buckyu kernel: Code: ff 4c 8b bd 98 e4 ff ff 48 89 b5 f0 e9 ff ff 48 89 bd f8 e9 ff ff eb 12 4c 89 f8 48 83 c0 08 49 89 c7 48 8b 00 48 85 c0 74 11 <80> 78 38 00 74 e8 48 8b 78 30 e8 5d d2 ff ff eb dd 48 8b 85 70 e4>>
July 27Jul 27 On 7/11/2026 at 7:24 AM, bucky2780 said:I recently installed/uninstalled the sr-iov plugin... to ensure it works as it is supposed to...I do get these worrying error messages every time I reboot unraid... particularly the segfault in igpu_top is a little worrying.The plugin does seem to work... but my system is a litlte unstable...What do you think about these error messages ? Benign or not ?>>Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] ERROR GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF1 state (-EPROTO)Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] ERROR GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102Jul 11 05:57:02 buckyu kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save >>In response to my earlier post, I am pleased to confirm I got the sriov plugin to cleanly install in my unraid system. Sharing it here, since it may help someone else.After tearing my hair out, I checked back into the Asrock Rack bios, and sure enough I found an additional parameter that said something like "start SR-IOV at boot". I ticked this and that seemed to do the trick.This is in addition to the normal SR-IOV option which was already ticked.Live an learn.>>BTW, still unable to get a cachyos guest to cleanly use the VF. I get some horrible errors in dmesg, despite having installed via the aur the dkms sriov package.If anyone here has been able to get their cachyos to cooperate, would appreciate on how to get that done. Do I need to blacklist the xe driver? i915 driver ? What ?
July 30Jul 30 Just a heads up for Unraid 7.2.8 and SR-IOV users.SRIOV currently doesn't compile against Kernel 6.12.98 which Unraid 7.2.8 is based on, so to speak, don't upgrade if you need SRIOV support.An issue was already opened in their GitHub but I think they are a bit exhausted supporting that many Kernel versions and it will take time to be updated so that it works again.
Saturday at 04:08 PM4 days Fix Intel iGPU SR-IOV on Unraid 7.3.2My SetupUnraid 7.3.2Kernel: 6.18.38-UnraidCPU: Intel Core i3-12100iGPU: Intel UHD Graphics 730 (8086:4692)SR-IOV driver: i915-sriov 2026.05.06Guests: Windows 11 and FnOSVM type: Q35 + OVMFProblemsFnOS detected the Intel VF but could not initialize it. The guest log reported:BAR 0: can't assign; no spaceWindows 11 detected Intel UHD Graphics 730 but reported Code 43.CausesThere were two problems:The Q35 PCIe root-port memory window was too small for the Intel VF.Windows VBS/Hypervisor caused Code 43.Fix for Both FnOS and Windows 11Shut down the VM, then open:Unraid → VMs → Edit → XML ViewChange the first XML line from:<domain type='kvm'>To:<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>Add the following lines immediately before the final </domain> line:qemu:commandline<qemu:arg value='-global'/><qemu:arg value='pcie-root-port.mem-reserve=32M'/></qemu:commandline>Save the XML and start the VM.FnOS also needs an i915-sriov guest driver built for its exact kernel.My FnOS configuration:Kernel: 6.18.18.c1032-trimGuest driver: i915-sriov 2026.05.06After these changes, FnOS successfully entered SR-IOV VF mode and loaded the i915 driver.Additional Fix for Windows 11Open “Turn Windows features on or off” and disable:Hyper-VVirtual Machine PlatformWindows Hypervisor PlatformThen open PowerShell as Administrator and run:bcdedit /set hypervisorlaunchtype offFully shut down the VM:shutdown /s /t 0Wait until Unraid shows the VM as stopped, then start it again.ResultFnOS: Intel VF successfully binds to i915.Windows 11: Intel UHD Graphics 730 Code 43 disappears.Both VMs require:pcie-root-port.mem-reserve=32MWindows 11 additionally requires:hypervisorlaunchtype off Edited Saturday at 04:12 PM4 days by ledemon
Yesterday at 01:57 AM1 day On 5/22/2026 at 10:43 AM, Encore said:will this work now on 7.3 with i5 14500 ?if i passtrough it to my windows guest, i can install the intel display driver, devicemanager shows all ok, but parsec still uses software renderer and can run furmark etc.edit:ok, worked, but my whole igpu crashs after VM shutdown .. need to do :echo 1 > /sys/bus/pci/rescanin unraid shell + add VFs back (no restart nessesary , worked again after)but after each VM reboot / shutdown, the igpu crashs and i need rescan and readd the VFs, any solution for this?Hey everyone,I was FINALLY!!!! able to solve my problem. I was facing the exact same issue with a new CPU (Ultra 250K PLUS) as described in the quote: after shutting down an SR-IOV VM, the host iGPU would crash, and I had to reboot or perform a PCIe rescan.I spent over 5 hours with ChatGPT and FINALLY GOT IT WORKING!!!!!!!!!!I had everything we did summarized for posterity, because otherwise I honestly wouldn't remember all of it :DI strongly suspect the main reason was that I was using the same Unraid USB stick that I had used years ago with an older Intel processor, which used GVT-g instead of SR-IOV.So -> if you're having the same problem as me, where the host GPU crashes after SR-IOV passthrough, and you're using the same Unraid stick that you previously used with older Intel CPUs, check the guide below!Here's the write-up from ChatGPT — because I definitely wouldn't be able to put it all back together myself :D#####################If anyone knows how I can simply hide the "big text" behind a spoiler or something, so that only people who are interested have to expand it, please let me know ^^ BBCode doesn't seem to work.#####################[spoiler]Intel iGPU SR-IOV with Arrow Lake on Unraid 7.3.2Intel Core Ultra 5 250K Plus · Arrow Lake-S · i915 SR-IOV · VFIO · Windows 11 VMShort version:I wanted to pass through the integrated Intel GPU of my Arrow Lake system to a Windows VM using SR-IOV. The VM itself worked, but when shutting down the VM, the entire iGPU would sometimes disappear from the PCI bus — including the Physical Function.After a lengthy troubleshooting process, it turned out that there was still an old GVT-g/libvirt hook on the system that was also accessing the Intel iGPU.After removing the old hook, both the PF and VF remained present even after multiple VM start/stop cycles.Important: During troubleshooting I also compiled a custom Strongtz i915-SR-IOV driver against the Unraid kernel. In hindsight, I cannot say with certainty whether this compilation was actually necessary. The decisive fix was very likely removing the old GVT-g hook.My setupUnraid: 7.3.2 Kernel: 6.18.38-Unraid CPU: Intel Core Ultra 5 250K Plus iGPU: Intel Arrow Lake-S PCI ID: 8086:7d67 iGPU PF: 00:02.0 iGPU VF: 00:02.1 VM: Windows 11The NVIDIA GPU in the system is irrelevant for this guide.The actual problemThe Intel iGPU could basically be split using SR-IOV.After enabling it, the following appeared:00:02.0 Intel Graphics -> PF 00:02.1 Intel Graphics -> VFThe VF was bound to vfio-pci and passed through to the Windows VM.At first, everything looked good.The problem occurred when shutting down the VM.Sometimes afterwards:lspci -nn -s 00:02would return nothing, or the devices would disappear from /sys.So it wasn't just:00:02.1that disappeared.The:00:02.0was gone as well.That was the really interesting part.First suspicion: VFIO/FLRNaturally, the first suspicion was that the VFIO reset of the VF was leaving the iGPU in a broken state.During VM shutdown, the logs showed:vfio-pci 0000:00:02.1: resetting i915 0000:00:02.0: VF1 FLR vfio-pci 0000:00:02.1: reset doneThat looked suspicious at first.So I tested the individual steps manually.Test 1 – Resetting the VF directlyecho 1 > /sys/bus/pci/devices/0000:00:02.1/resetResult:i915 0000:00:02.0: VF1 FLRAfterwards, both devices were still present:00:02.0 00:02.1This made a normal VF FLR alone as the cause rather unlikely.Test 2 – VFIO resetThe VF was bound to vfio-pci and then reset as well.vfio-pci 0000:00:02.1: resetting i915 0000:00:02.0: VF1 FLR vfio-pci 0000:00:02.1: reset doneAgain, afterwards:00:02.0 00:02.1were still present.Test 3 – VFIO unbindI also tested the unbind separately:echo 0000:00:02.1 > /sys/bus/pci/drivers/vfio-pci/unbindAgain, the PF remained present.At this point, it increasingly looked like the normal VFIO lifecycle alone wasn't causing the problem.Then I started looking into the i915 driverSince Arrow Lake SR-IOV wasn't working out of the box with the standard Unraid i915 driver, I used the Strongtz i915-SR-IOV driver.My kernel was:6.18.38-UnraidSince the Unraid system itself didn't have a complete kernel build environment, I used the kernel-build container from ich777.The resulting build was:2026.03.05.6-sriovbuilt against:6.18.38-UnraidThe build itself worked.The module subsequently reported:version: 2026.03.05.6-sriov vermagic: 6.18.38-Unraid SMP preempt mod_unloadSide issue when loading the moduleI also ran into a separate issue while loading the module.The compressed .ko.xz file could not be loaded directly via insmod:decompression failed with status 6After manually decompressing it, however, the module loaded successfully:xz -dc .../i915.ko.xz > /tmp/i915.ko insmod /tmp/i915.ko force_probe=7d67 enable_guc=3 max_vfs=1The i915 driver then started correctly:Found meteorlake (device ID 7d67) Running in SR-IOV PF modeand:1 VFs could be associated with this PFSo at least I knew that the custom driver itself was basically working.And then came the interesting partDuring troubleshooting, I eventually took a closer look at what was actually happening when starting and stopping the VM.In:/etc/libvirt/hooks/qemuthere was still old code from my previous Intel GVT-g configuration.The hook contained, among other things, references to:00:02.0and:mdev_supported_types/i915-GVTg_V5_4The code created a GVT-g mdev when the VM started and removed it when the VM ended.That was pretty obviously wrong for my new SR-IOV setup.So I effectively had two different mechanisms trying to manage the same Intel GPU:GVT-g / mdev + SR-IOV / PF + VFI honestly should have checked this much earlier.Removed the old GVT-g codeI removed only the old GVT-g sections from:/etc/libvirt/hooks/qemuThe relevant code was:"if ($argv[2] 'prepare' && $argv[3] 'begin'){ shell_exec('echo "$(cat /boot/config/plugins/intel-gvt-g/vms.conf | grep "Windows 11" | awk -F\\'[{}]\\' \\'{print $6}\\')" > /sys/devices/pci0000\\:00/0000\\:00\\:02.0/mdev_supported_types/i915-GVTg_V5_4/create'); } if ($argv[2] 'release' && $argv[3] 'end'){ shell_exec('echo 1 > /sys/devices/pci0000\\:00/0000\\:00\\:02.0/"$(cat /boot/config/plugins/intel-gvt-g/vms.conf | grep "Windows 11" | awk -F\\'[{}]\\' \\'{print $6}\\')"/remove'); }"I kept the rest of the hook because it still contains other VFIO-related functions.After that, the VF was created normally again:echo 1 > /sys/bus/pci/devices/0000:00:02.0/sriov_numvfsAnd:00:02.0 -> i915 00:02.1 -> vfio-pciFirst test afterwardsStarted the VM.Used the VM.Shut down the VM.Afterwards:lspci -nn -s 00:02still showed:00:02.0 VGA compatible controller: Intel Corporation Arrow Lake-S [8086:7d67] 00:02.1 VGA compatible controller: Intel Corporation Arrow Lake-S [8086:7d67]That was the first really interesting success.Second testI went through the entire cycle again.During shutdown, I once again saw:i915 0000:00:02.0: VF1 FLRBut this time the devices did not disappear.Afterwards:readlink -f /sys/bus/pci/devices/0000:00:02.0/driverreturned:/sys/bus/pci/drivers/i915And:readlink -f /sys/bus/pci/devices/0000:00:02.1/driverreturned:/sys/bus/pci/drivers/vfio-pciAlso:cat /sys/bus/pci/devices/0000:00:02.0/sriov_numvfsreturned:1So the state after shutting down the VM was exactly what it should be.So what was actually the solution?Here I have to be a little careful.During troubleshooting, I changed several things:Installed the Strongtz i915-SR-IOV driverCompiled the driver against the Unraid kernelEnabled SR-IOVAdjusted the VFIO configurationPerformed various reset/unbind testsFound and removed the old GVT-g/libvirt hookTherefore, I cannot say with 100% certainty that the custom i915 build itself was necessary.The decisive A/B difference we observed in the end was:Beforei915 SR-IOV + old GVT-g hook ↓ VM shutdown ↓ VF1 FLR ↓ 00:02.0 + 00:02.1 disappearAfteri915 SR-IOV + no old GVT-g hook ↓ VM shutdown ↓ VF1 FLR ↓ 00:02.0 remains 00:02.1 remainsTherefore, my current assessment is:The old GVT-g hook was very likely the actual cause of the entire iGPU disappearing.The custom i915 driver was useful and/or necessary for SR-IOV support, but whether that build actually fixed the original shutdown issue has not been proven.What I would check first todayIf someone has the same problem, I would not immediately start compiling the kernel.First, check:grep -niE 'gvt|mdev|i915-GVT|00:02\.0' /etc/libvirt/hooks/qemuIf old GVT-g configuration shows up there:remove or disable it first.Then test the VM again.Only if SR-IOV itself doesn't work would I start looking into the appropriate i915-SR-IOV driver.My working configurationAt the moment, the relevant part looks like this:00:02.0 -> i915 00:02.1 -> vfio-pciAnd:sriov_numvfs = 1 (up to 7 work)Kernel parameters:intel_iommu=on iommu=pt i915.force_probe=7d67 i915.enable_guc=3 i915.max_vfs=1 module_blacklist=xexe remains disabled because I am using i915 for this configuration.A few more things I learned along the wayA VF FLR is not automatically an errorThis message:i915 0000:00:02.0: VF1 FLRlooks scary at first, but it is expected during a VFIO lifecycle.What matters is what happens afterwards.If:00:02.0 00:02.1are still present afterwards, the reset apparently completed cleanly.If the PF disappears, look more closelyThe VM receives:00:02.1But if afterwards:00:02.0also disappears, I wouldn't simply assume "VFIO reset is broken."In that case, check whether something is touching, unbinding, removing, or reconfiguring the PF itself.Old GVT-g configuration is easy to overlookThis was ultimately the key issue for me.I had mentally written off the old GVT-g configuration a long time ago, but the libvirt hook was still there.That's exactly the kind of old configuration that can be really nasty when switching to SR-IOV, because it may not cause any problems during normal operation.It only kicks in again when the VM is started/stopped.Current statusAfter removing the old GVT-g hook, I tested several complete VM cycles.The relevant state remains:PF: 00:02.0 -> i915 VF: 00:02.1 -> vfio-pciAfter shutting down the VM:00:02.0 -> present 00:02.1 -> presentAnd the expected:i915 0000:00:02.0: VF1 FLRstill appears in the log.So the original "iGPU disappears after VM shutdown" issue is currently resolved.Addendum: The build containerThe Docker container that I only used for building the kernel is not required at runtime.After successfully building the driver, you can remove it again:docker rm -f i915-sriov-buildI would, however, keep the installed i915-SR-IOV package for now as long as the current SR-IOV configuration depends on it.[/spoiler] Edited yesterday at 02:35 AM1 day by Encore
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.