Hey,

so i've had this running for quite a while, but i restarted my VM today and it just stops working, it gives Code 43 and the following in the VM Log:

char device redirected to /dev/pts/3 (label charserial0)

2025-07-22T15:22:50.062308Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:50.062353Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -2 (No such file or directory)

2025-07-22T15:22:50.140639Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:50.140658Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

2025-07-22T15:22:54.230866Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:54.230889Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

2025-07-22T15:22:54.293984Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:54.294013Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

2025-07-22T15:22:54.443558Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:54.443582Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

2025-07-22T15:22:54.464231Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:54.464257Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

2025-07-22T15:22:58.141018Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:58.141040Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

This issue seem to be common, so i checked all the steps i could find:

• Reboot of VM

• Reboot of Server

• Reassigned VFIO from 3 to 2

• Tried VFIO booting, but that wasn't recommended and or working

• Assigned .bin for BIOS

• Uninstalled plugin > Reboot > Installed plugin

• Tried making new VM config

• Tried different versions of Intel drivers > All of them give code 43

I'm quite out of options, anyone else have ideas?

3 hours ago, Mirano said:

Hey,

so i've had this running for quite a while, but i restarted my VM today and it just stops working, it gives Code 43 and the following in the VM Log:

char device redirected to /dev/pts/3 (label charserial0)

2025-07-22T15:22:50.062308Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:50.062353Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -2 (No such file or directory)

2025-07-22T15:22:50.140639Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:50.140658Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

2025-07-22T15:22:54.230866Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:54.230889Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

2025-07-22T15:22:54.293984Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:54.294013Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

2025-07-22T15:22:54.443558Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:54.443582Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

2025-07-22T15:22:54.464231Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:54.464257Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

2025-07-22T15:22:58.141018Z qemu-system-x86_64: VFIO_MAP_DMA failed: Invalid argument

2025-07-22T15:22:58.141040Z qemu-system-x86_64: vfio_container_dma_map(0x5606a2d63de0, 0x382800000000, 0x20000000, 0x154100000000) = -22 (Invalid argument)

This issue seem to be common, so i checked all the steps i could find:

• Reboot of VM

• Reboot of Server

• Reassigned VFIO from 3 to 2

• Tried VFIO booting, but that wasn't recommended and or working

• Assigned .bin for BIOS

• Uninstalled plugin > Reboot > Installed plugin

• Tried making new VM config

• Tried different versions of Intel drivers > All of them give code 43

I'm quite out of options, anyone else have ideas?

Update,

I made a new VM and if i boot it up, first connect to RDP, delete the code 43 driver, wait 5 minutes then connect with Parsec it's got a working driver. Really strange tho.

On 3/8/2025 at 3:17 AM, nyavana said:

Quick question, What is the latest processor that supports this plugin?

According to Intel, 13th gen (Raptor Lake), 14th gen (Raptor Lake Refresh), and ultra 2 series (Arrow Lake) all supports SRIOV.

 

Background:

I am thinking about upgrading from 12700k to 265K as current motherboard can't support more ram.

If Arrow Lake is currently unsupported due to driver or kernel issue, where can I find the source so I can check progress myself?

Thanks in advance 

Seems like XE graphics are setting SRIOV support since kernel 6.1.7, any estimated time for Unraid to update?

https://github.com/intel/linux-intel-lts/issues/33#issuecomment-3116317907

Edited August 28, 2025Aug 28 by nyavana

5 hours ago, nyavana said:

Seems like XE graphics are setting SRIOV support since kernel 6.1.7, any estimated time for Unraid to update?

https://github.com/intel/linux-intel-lts/issues/33#issuecomment-3116317907

Kernel 6.17 has not been released it is still in RC. If it becomes LTS and when ZFS supports it would likely been in the next Unraid release. But the sriov I believe is only going to be support on Battle mage pro cards. ARC cards are not supported.

https://www.phoronix.com/news/Intel-SR-IOV-Only-For-Arc-Pro

Hopefully kernel 6.18 really does have support for SR IOV XE drivers, when using ADL.

On 7/23/2025 at 6:46 AM, Mirano said:

Update,

I made a new VM and if i boot it up, first connect to RDP, delete the code 43 driver, wait 5 minutes then connect with Parsec it's got a working driver. Really strange tho.

Not sure this will help, but I have had similar issues.
My CPU is an Intel 14600K, and I have now seen the following issues and "workarounds":

For the "VFIO_MAP_DMA failed: Invalid argument" error in the VM logs => see here for explanation: https://forum.level1techs.com/t/looking-glass-vm-to-vm-not-working/227549/2

But basically you need to add the "maxphysaddr" line in your VM XML config, as following

<cpu mode='host-passthrough' check='none' migratable='on'>

<topology sockets='1' dies='1' clusters='1' cores='6' threads='2'/>

<cache mode='passthrough'/>

<maxphysaddr mode='passthrough' limit='39'/>

</cpu>

For the driver error code -43 in windows 11 VM, I noticed that it is linked to a specific driver version that was installed by Windows Update, I fixed it by "rolling back" to the previous installed driver that happened to be in fact more recent!
Here the driver that seems to be working for me:


Hope this helps a bit!

Edited September 11, 2025Sep 11 by LoloNZ

error filling logs.i also noticed that the support link in plugin settings page takes me to the original zhtengw thread.

Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF1 state (-EPROTO)
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF2 state (-EPROTO)
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF3 state (-EPROTO)
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF4 state (-EPROTO)
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF5 state (-EPROTO)
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF6 state (-EPROTO)
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: CT: Sending action 0x550b failed (-EIO) status=0XE0000102
Sep 12 17:03:36 Tower kernel: i915 0000:00:02.0: [drm] GT0: IOV: Failed to save VF7 state (-EPROTO)

Hello, I would like to report an issue. After upgrading from 7.1.4 to 7.2.0 beta3, the intel-i915-sriov feature has become non-functional, as shown in the image. Thank you for your efforts.

I would like to report an issue. After upgrading from 7.1.4 to 7.2.0 beta3，I reinstalled the plugin using the following link and restarted Unraid, and i915 Sriov worked properly. But when using Intel Core Graphics for the virtual machine, there is this warning. I tried restarting Unraid again, but it still has the same warning. The virtual machine cannot start. What's the problem? Thank you! I edited the virtual machine, deleted the 2nd Graphics Card, and saved it. Add 2nd Graphics Card again and save. As shown in the picture, it is still this warning. Restarting Unraid still has this warning

https://raw.githubusercontent.com/giganode/unraid-i915-sriov/master/i915-sriov.plg

On 9/23/2025 at 9:53 PM, HDLynx said:

Hello, I would like to report an issue. After upgrading from 7.1.4 to 7.2.0 beta3, the intel-i915-sriov feature has become non-functional, as shown in the image. Thank you for your efforts.

You need to scroll to the right side to see the save button (at least that is what I do). Or you can manually edit the same setting in Tool -> System Driver -> IOVA driver to “your reference number” (without quoting). And then you rehoot Unraid to apply changes.

On 10/2/2025 at 3:56 AM, Johnny Tai said:

You need to scroll to the right side to see the save button (at least that is what I do). Or you can manually edit the same setting in Tool -> System Driver -> IOVA driver to “your reference number” (without quoting). And then you rehoot Unraid to apply changes.

I have scrolled to the right, saved and restarted unraid, but in reality, this does not take effect. PCI has a warning, I have reviewed the release notes for version 7.2, which includes information about 'VM Manager'

Feature: Save PCI hardware data, warn if hardware used by VM changes”， If there are any changes to PCI in version 7.2, go to Tools ->System Devices. Click on 'acknowledge all PCI changes', the warning disappears, and the issue is resolved.

18 hours ago, HDLynx said:

I have scrolled to the right, saved and restarted unraid, but in reality, this does not take effect. PCI has a warning, I have reviewed the release notes for version 7.2, which includes information about 'VM Manager'

Feature: Save PCI hardware data, warn if hardware used by VM changes”， If there are any changes to PCI in version 7.2, go to Tools ->System Devices. Click on 'acknowledge all PCI changes', the warning disappears, and the issue is resolved.

You can do at the PCI device level also in system devices by clicking on the warning triangle. I added the feature to stop VMs starting if new hardware has been added an the VMs have not been updated as this can cause issues of correcting the wrong device to a VM, i.e. the HBA which would mean the disks would disappear.

5 hours ago, SimonF said:

You can do at the PCI device level also in system devices by clicking on the warning triangle. I added the feature to stop VMs starting if new hardware has been added an the VMs have not been updated as this can cause issues of correcting the wrong device to a VM, i.e. the HBA which would mean the disks would disappear.

Okay, thanks.

On 3/7/2025 at 10:30 AM, yuzufilm said:

Hi there, new here. I installed intel GPU TOP and then this SR-IOV plugin for my 12700K. I cannot get my VM to see the iGPU/UHD 770. I've installed the default Windows Update Intel display drivers and when I tried using the driver package from Intel's website I get an error saying I don't have any compatible devices. I don't have this issue when I bind the iGPU and fully passthrough it without the SR-IOV plugin and use a dummy HDMI cable - but I'd obviously like to have the VFs so I can do things like encode with Handbrake and have a VM with iGPU capabilities.

 

Here's my diagnostics and XML and some screenshots. Thank you!

yuzu-nas-diagnostics-20250307-0922.zip xml copy.txt

Whenever you have this issue -the VM does not see, or does not recognize the hardware in Task Manger (image 1) and you cannot hardware accelerate- the method that worked for me was recreating the VM (not cloning it)(image 2-if you need help doing this). I recreated the vm with this workaround: i pass through Virtual for graphics card, then pass through the VF in 2nd graphics card (see image 3) [I had some minor issues of it freezing up after a few minutes in Splashtop, or RDP from weak laptop - it doesn’t freeze when RDP from VM with 3080gpu passed through though.].

I seen @alturismo use Parsec but it’s hard to find info on how it works and the right way to use it and set it up -

1. i install the parsec display drivers

2. i can access from another computer via parsec remote?

3. can i access via phone somehow? i’m on iphone i don’t see in store.

4. i use Splashtop, but the vf isn’t passed though properly without also passing through virtual graphics first.

i’m hoping someone can guide US ALL here on how to do this properly step by step. I’d be really grateful.

Edited October 12, 2025Oct 12 by xlucero1
Clarified how to see the igpu in task manager allowing hardware acceleration by recreating the vm.

9 minutes ago, xlucero1 said:

i install the parsec display drivers

i even use the vdd driver (not parsec) but shouldnt matter

https://github.com/VirtualDrivers/Virtual-Display-Driver

installing intel drivers then the iGPU should initialize properly and no more code 43 etc.

afterwards, you can use any tool for remote, depending now what you like and how good it works, personal experience

VNC like TightVNC which makes use of hw acc, lowest quality

RDP, quite ok and usually my favor for fast access, good enough for browsing and office

"Game" Streamers Apps like Parsec, sunshine/moonlight, ... best experience (almost bare metal)

Apps like Teamviewer, Splashtop, Anydesk, Chrome remote, whatever ...

yes, also makes somehow use of hw acc but not compareable to gamestreaming, you are more on RDP Level there ...

in short my steps

1/ setup VM via VNC

2/ install virtual display driver

3/ install a native VNC and/or enable RDP on the mashine

4/ stop VM, assign vgpu as ONLY display, start VM

5/ access your VM via native VNC or RDP

6/ install Intel drivers, check if all is ok (no erros in device manager, driver)

7/ install your remote tool/s and test and compare

20 hours ago, alturismo said:

1/ setup VM via VNC

So if I somehow do not see the igpu in task manager, do you also believe the only way to recover it properly is to recreate the VM as I have mentioned there in image 2? I have tried a bunch of other stuff, including following your steps, but I cannot download the iGPU drivers, since the iGPU is not even being recognized. The only way it was recognized is when i recreated it again.

Thank you very much for your awesome response earlier. that was helpful and helped clarify for the process for setting up VM!

1 hour ago, xlucero1 said:

but I cannot download the iGPU drivers, since the iGPU is not even being recognized. The only way it was recognized is when i recreated it again.

thats clear, no vgpu in VM, no driver, no fun ;)

if you "loose" the vgpu and you need to recreate it ... the issue is pretty sure either

some missconfiguration

hardware doesnt like sr-iov

most common errors, vfio bind, extra syslinux entries, ... this plugin should be

1/ installed

2/ choose how many vgpu are wanted (i always use 2)

thats it, from here on as mentioned above, i never had a missed vgpu afterwards, yes, in the beginning i had some code 43 issues inside the VM iGPU drivers, but with a virtual display and as only gpu in VM, never since then.

I just tried to upgrade to 7.2.0-rc.2 and this plugin didn't upgrade. Please see the attached screenshot and diagnostics. And let me know what else you need.

bb-8-diagnostics-20251017-1611.zip

Edited October 17, 2025Oct 17 by shaunmccloud
Added diagnostics

7 hours ago, shaunmccloud said:

I just tried to upgrade to 7.2.0-rc.2 and this plugin didn't upgrade. Please see the attached screenshot and diagnostics. And let me know what else you need.

bb-8-diagnostics-20251017-1611.zip

Same issue here...

30 minutes ago, neunghaha28 said:

For all who are in need of a plugin package for Unraid 7.2.0-rc.2 here it is:

Please don't distribute Packages like that, wouldn't it be better to create a PR here with the patch for newer Kernels:

https://github.com/giganode/unraid-i915-sriov

You complicate the installation for users unnecessary... and for users who already upgraded to rc2 this won't even work.

8 minutes ago, ich777 said:

Please don't distribute Packages like that, wouldn't it be better to create a PR here with the patch for newer Kernels:

https://github.com/giganode/unraid-i915-sriov

You complicate the installation for users unnecessary... and for users who already upgraded to rc2 this won't even work.

Yes it is quite complicated and the statement that already upgraded to rc2 does not work is not true. I upgraded to rc2 and followed the steps and it worked. Okay I will open a PR to make it easier for others.

2 minutes ago, neunghaha28 said:

Yes it is quite complicated and the statement that already upgraded to rc2 does not work is not true. I upgraded to rc2 and followed the steps and it worked.

Yes and no, but if someone mixes up the steps and try to install the plugin first then it wont, I'm just thinking one step further since I designed the plugin. ;)

Just make sure that the patch is in the source folder, that would help a lot, since I don't have much time to troubleshoot why it's not working currently, or you could also push a PR to: https://github.com/strongtz/i915-sriov-dkms

19 minutes ago, ich777 said:

Please don't distribute Packages like that, wouldn't it be better to create a PR here with the patch for newer Kernels:

https://github.com/giganode/unraid-i915-sriov

You complicate the installation for users unnecessary... and for users who already upgraded to rc2 this won't even work.

https://github.com/giganode/unraid-i915-sriov/pull/1/files

Thank you, I've already compiled and pushed the plugin package, however the latest commit is this one here which seems to compile fine:
#518611bcacfb0493a178e23acae071814baa4572

(from 2025-08-30)

@shaunmccloud & @no1warr1or, it is now safe to reboot, the plugin packages should be pulled at reboot, if not install the plugin after you are on RC2 and reboot again.

4 hours ago, ich777 said:

Thank you, I've already compiled and pushed the plugin package, however the latest commit is this one here which seems to compile fine:
#518611bcacfb0493a178e23acae071814baa4572

(from 2025-08-30)

@shaunmccloud & @no1warr1or, it is now safe to reboot, the plugin packages should be pulled at reboot, if not install the plugin after you are on RC2 and reboot again.

I actually rolled the update back, so I'll re-update then reboot.