Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[RFC]Rebase the dkms module on the linux-intel-lts 6.6/linux branch #207

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

[RFC]Rebase the dkms module on the linux-intel-lts 6.6/linux branch #207

wants to merge 4 commits into from

Conversation

bbaa-bbaa
Copy link
Contributor

@bbaa-bbaa bbaa-bbaa commented Oct 6, 2024 •
edited
Loading

Rebase the dkms module on the linux-intel-lts 6.6/linux branch
Based on linux-intel-lts#lts-v6.6.50-linux-240925T091328Z without color management updates (https://github.com/bbaa-bbaa/linux-intel-lts/tree/6bf2df6d263e101cbb9a2c996fa6de30ddd13e01/drivers/gpu/drm/i915)

Test on kernel 6.11.2-zen1 with ArchLinux / 6.8.12-2-pve with Proxmox VE
Other versions may need more testing.

Minimum kernel version: 6.8
The upstream tree of Intel seems to rely on features backported from 6.8, and more research is needed to make the module work in the 6.6 kernel.

Migrating to the 6.6 branch means that we need to drop support for kernels before 6.8.
We may need to create a new branch to preserve the original 6.1 kernel-based branch.

@bbaa-bbaa bbaa-bbaa marked this pull request as draft October 6, 2024 11:52
@bbaa-bbaa bbaa-bbaa changed the title [WIP]Rebase the dkms module on the linux-intel-lts 6.6/linux branch [RFC]Rebase the dkms module on the linux-intel-lts 6.6/linux branch Oct 7, 2024
@bbaa-bbaa bbaa-bbaa marked this pull request as ready for review October 7, 2024 12:46
This was referenced Oct 8, 2024
Open
Open
Open
@RaidenSummoner
Copy link

RaidenSummoner commented Oct 24, 2024 •
edited
Loading

I have tried your patch on pve which uses kernel 6.8.12-2, when I reboot the guest machine, it still report an error:

  • [ 609.615343] i915 0000:00:02.0: [drm] ERROR [CRTC:80:pipe A] mismatch in post_csc_lut hw_state doesn't match sw_state

  • [ 609.615353] ------------[ cut here ]------------

  • [ 609.615354] i915 0000:00:02.0: pipe state doesn't match!

  • [ 609.615397] WARNING: CPU: 1 PID: 980 at /var/lib/dkms/i915-sriov-dkms/2024.10.07/build/drivers/gpu/drm/i915/display/intel_modeset_verify.c:222 intel_modeset_verify_crtc+0x5d6/0x6b0 [i915]

  • [ 609.615558] Modules linked in: tcp_diag inet_diag ebtable_filter ebtables ip_set ip6table_raw iptable_raw ip6table_filter ip6_tables xt_nat xt_tcpudp veth xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype iptable_filter nf_tables nvme_fabrics overlay qrtr bonding tls softdog sunrpc binfmt_misc nfnetlink_log nfnetlink intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_sof_pci_intel_tgl snd_sof_intel_hda_common kvm soundwire_intel snd_sof_intel_hda_mlink soundwire_cadence snd_sof_intel_hda crct10dif_pclmul snd_sof_pci polyval_clmulni snd_sof_xtensa_dsp polyval_generic ghash_clmulni_intel snd_sof sha256_ssse3 snd_sof_utils sha1_ssse3 snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match aesni_intel snd_soc_acpi crypto_simd soundwire_generic_allocation snd_hda_codec_hdmi cryptd snd_hda_codec_realtek snd_hda_codec_generic soundwire_bus snd_soc_core snd_compress ac97_bus

  • [ 609.615599] snd_pcm_dmaengine snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec cmdlinepart snd_hda_core snd_hwdep snd_pcm spi_nor rapl snd_timer intel_cstate serio_raw wmi_bmof pcspkr mtd snd mei_me soundcore ee1004 mei igen6_edac intel_pmc_core intel_vsec pmt_telemetry pmt_class acpi_pad acpi_tad mac_hid zfs(PO) spl(O) vhost_net vhost vhost_iotlb tap vfio_pci vfio_pci_core irqbypass vfio_iommu_type1 vfio iommufd parport_pc ppdev lp parport efi_pstore dmi_sysfs ip_tables x_tables autofs4 btrfs blake2b_generic xor raid6_pq libcrc32c i915(OE) xe drm_gpuvm drm_exec gpu_sched drm_buddy i2c_algo_bit drm_suballoc_helper drm_ttm_helper ttm nvme spi_intel_pci nvme_core drm_display_helper r8169 xhci_pci xhci_pci_renesas crc32_pclmul psmouse spi_intel realtek cec nvme_auth i2c_i801 i2c_smbus xhci_hcd ahci rc_core libahci video wmi

  • [ 609.615646] CPU: 1 PID: 980 Comm: Xorg Tainted: P U W OE 6.8.12-2-pve SR-IOV cannot be turned on. #1

  • [ 609.615648] Hardware name: Intel ITX-N100-2L/ITX-N100-2L, BIOS IN100L06 07/17/2024

  • [ 609.615650] RIP: 0010:intel_modeset_verify_crtc+0x5d6/0x6b0 [i915]

  • [ 609.615781] Code: fc ff ff 49 8b 7f 08 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 ac 59 dc db 48 89 da 48 c7 c7 b0 d2 d4 c0 48 89 c6 e8 ea 5b 3d db <0f> 0b e9 89 fd ff ff 80 fb 01 0f 87 f8 ec 0c 00 41 0f b6 8c 24 50

  • [ 609.615783] RSP: 0018:ffff9d68445f7838 EFLAGS: 00010246

  • [ 609.615786] RAX: 0000000000000000 RBX: ffff8c89414b88a0 RCX: 0000000000000000

  • [ 609.615787] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000

  • [ 609.615788] RBP: ffff9d68445f78b0 R08: 0000000000000000 R09: 0000000000000000

  • [ 609.615790] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8c894bbb2000

  • [ 609.615791] R13: ffff8c8943882000 R14: ffff8c8960306000 R15: ffff8c8963ca8000

  • [ 609.615792] FS: 000077cacce1cac0(0000) GS:ffff8c8cafa80000(0000) knlGS:0000000000000000

  • [ 609.615794] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

  • [ 609.615796] CR2: 00007ffa84d627d8 CR3: 00000001082f0005 CR4: 0000000000f72ef0

  • [ 609.615798] PKRU: 55555554

  • [ 609.615799] Call Trace:

  • [ 609.615800]

  • [ 609.615804] ? show_regs+0x6d/0x80

  • [ 609.615810] ? __warn+0x89/0x160

  • [ 609.615813] ? intel_modeset_verify_crtc+0x5d6/0x6b0 [i915]

  • [ 609.615959] ? report_bug+0x17e/0x1b0

  • [ 609.615963] ? handle_bug+0x46/0x90

  • [ 609.615966] ? exc_invalid_op+0x18/0x80

  • [ 609.615968] ? asm_exc_invalid_op+0x1b/0x20

  • [ 609.615972] ? intel_modeset_verify_crtc+0x5d6/0x6b0 [i915]

  • [ 609.616110] ? intel_modeset_verify_crtc+0x5d6/0x6b0 [i915]

  • [ 609.616243] ? intel_fbc_nuke+0x42/0xd0 [i915]

  • [ 609.616378] intel_atomic_commit_tail+0x974/0xf60 [i915]

  • [ 609.616528] intel_atomic_commit+0x3bd/0x410 [i915]

  • [ 609.616660] drm_atomic_commit+0x96/0xd0

  • [ 609.616664] ? __pfx___drm_printfn_info+0x10/0x10

  • [ 609.616666] drm_atomic_connector_commit_dpms+0xd7/0x100

  • [ 609.616669] drm_mode_obj_set_property_ioctl+0x1ad/0x3e0

  • [ 609.616672] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10

  • [ 609.616674] drm_connector_property_set_ioctl+0x3b/0x60

  • [ 609.616676] drm_ioctl_kernel+0xb9/0x120

  • [ 609.616678] drm_ioctl+0x2c2/0x530

  • [ 609.616680] ? __pfx_drm_connector_property_set_ioctl+0x10/0x10

  • [ 609.616682] __x64_sys_ioctl+0xa0/0xf0

  • [ 609.616686] x64_sys_call+0xa68/0x24b0

  • [ 609.616688] do_syscall_64+0x81/0x170

  • [ 609.616690] ? __x64_sys_setitimer+0x15b/0x1b0

  • [ 609.616694] ? syscall_exit_to_user_mode+0x89/0x260

  • [ 609.616697] ? do_syscall_64+0x8d/0x170

  • [ 609.616699] ? __sys_recvmsg+0xc6/0xe0

  • [ 609.616703] ? syscall_exit_to_user_mode+0x89/0x260

  • [ 609.616705] ? do_syscall_64+0x8d/0x170

  • [ 609.616707] ? syscall_exit_to_user_mode+0x89/0x260

  • [ 609.616709] ? do_syscall_64+0x8d/0x170

  • [ 609.616711] ? do_syscall_64+0x8d/0x170

  • [ 609.616713] ? irqentry_exit+0x43/0x50

  • [ 609.616716] entry_SYSCALL_64_after_hwframe+0x78/0x80

  • [ 609.616718] RIP: 0033:0x77caccb1cc5b

  • [ 609.616737] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00

  • [ 609.616738] RSP: 002b:00007ffd65f02a30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010

  • [ 609.616741] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000077caccb1cc5b

  • [ 609.616742] RDX: 00007ffd65f02ac0 RSI: 00000000c01064ab RDI: 0000000000000010

  • [ 609.616743] RBP: 00007ffd65f02ac0 R08: 0000000000000002 R09: 0000000000000000

  • [ 609.616744] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01064ab

  • [ 609.616745] R13: 0000000000000010 R14: 00005eeb050d6c00 R15: 00005eeb06d6d5a0

  • [ 609.616747]

  • [ 609.616748] ---[ end trace 0000000000000000 ]---

  • [ 621.996225] i915 0000:00:02.0: VF1 FLR

  • [ 649.356926] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 727

  • [ 651.404802] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 728

  • [ 653.452670] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 729

  • [ 655.500536] i915 0000:00:02.0: [drm] ERROR GT0: GUC: TLB invalidation response timed out for seqno 730

But my host device won't stuck after applying your patch, is this trace a great concern?
UPDATE: After uninstalling my desktop environment on PVE, I no more get this error and it stll works well now.

@bbaa-bbaa
Copy link
Contributor Author

bbaa-bbaa commented Oct 25, 2024 •
edited
Loading

But my host device won't stuck after applying your patch, is this trace a great concern?

I don't know.
post_csc_lut seems is a struct about color management. Due to color management in the upstream Intel repository depends on DRM changes that have not been merged into the mainline tree, I just simply reverted the relevant commits (https://github.com/bbaa-bbaa/linux-intel-lts/tree/6bf2df6d263e101cbb9a2c996fa6de30ddd13e01/drivers/gpu/drm/i915). There may be some unexpected side effects.

Could you add drm.debug=0x19f log_buf_len=4M to the kernel cmdline to provide more logs for investigation?

@admarty
Copy link

admarty commented Oct 26, 2024

Thank you for this fork! I had many errors in dmesg when using the original repo, but after trying your fork, all the errors are gone.
I'm using Proxmox VE 8.2, kernel 6.8.12-2-pve, on an Intel N100 CPU.

@RaidenSummoner
Copy link

RaidenSummoner commented Oct 26, 2024 •
edited
Loading

But my host device won't stuck after applying your patch, is this trace a great concern?

I don't know. post_csc_lut seems is a struct about color management. Due to color management in the upstream Intel repository depends on DRM changes that have not been merged into the mainline tree, I just simply reverted the relevant commits (https://github.com/bbaa-bbaa/linux-intel-lts/tree/6bf2df6d263e101cbb9a2c996fa6de30ddd13e01/drivers/gpu/drm/i915). There may be some unexpected side effects.

Could you add drm.debug=0x19f log_buf_len=4M to the kernel cmdline to provide more logs for investigation?

After uninstalling desktop environment, I no more get these errors, but my Windows 10/11 VM randomly either works well or gets error 43 in device manager and nothing can be found in dmesg, and I can't find any solutions to fix it, so I temporarily disabled it.

@admarty
Copy link

admarty commented Oct 26, 2024

But my host device won't stuck after applying your patch, is this trace a great concern?

I don't know. post_csc_lut seems is a struct about color management. Due to color management in the upstream Intel repository depends on DRM changes that have not been merged into the mainline tree, I just simply reverted the relevant commits (https://github.com/bbaa-bbaa/linux-intel-lts/tree/6bf2df6d263e101cbb9a2c996fa6de30ddd13e01/drivers/gpu/drm/i915). There may be some unexpected side effects.
Could you add drm.debug=0x19f log_buf_len=4M to the kernel cmdline to provide more logs for investigation?

After uninstalling desktop environment, I no more get these errors, but my Windows 10/11 VM randomly either works well or gets error 43 in device manager and nothing can be found in dmesg, and I can't find any solutions to fix it, so I temporarily disabled it.

Have you set the cpu = host?

@RaidenSummoner
Copy link

RaidenSummoner commented Oct 26, 2024 •
edited
Loading

But my host device won't stuck after applying your patch, is this trace a great concern?

I don't know. post_csc_lut seems is a struct about color management. Due to color management in the upstream Intel repository depends on DRM changes that have not been merged into the mainline tree, I just simply reverted the relevant commits (https://github.com/bbaa-bbaa/linux-intel-lts/tree/6bf2df6d263e101cbb9a2c996fa6de30ddd13e01/drivers/gpu/drm/i915). There may be some unexpected side effects.
Could you add drm.debug=0x19f log_buf_len=4M to the kernel cmdline to provide more logs for investigation?

After uninstalling desktop environment, I no more get these errors, but my Windows 10/11 VM randomly either works well or gets error 43 in device manager and nothing can be found in dmesg, and I can't find any solutions to fix it, so I temporarily disabled it.

Have you set the cpu = host?

Yes. This problem happens randomly. I have rebooted my VM for 10 times, 7 times works well and 3 times initialize failed with error 43.I found a solution:

  • Because Intel's driver fixes pciid to 02.0, when we use 02.1/2/3 and other sriov core graphics, it cannot be driven normally. Even if PCI-Express is checked in the direct sriov core graphics to show normal driving, some software will not work properly due to pciid, such as streaming media Jellyfin Emby, etc. cannot be hard-decoded and transcoded.

  • We need to specify the address of the direct core graphics in the virtual machine conf

  • nano /etc/pve/qemu-server/virtual machine serial number.conf

  • Add:

  • args: -set device.hostpci0.addr=02.0 -set device.hostpci0.x-igd-gms=0x2

but after trying it, GPU totally disappeared in my VM.

@admarty
Copy link

admarty commented Oct 26, 2024

But my host device won't stuck after applying your patch, is this trace a great concern?

I don't know. post_csc_lut seems is a struct about color management. Due to color management in the upstream Intel repository depends on DRM changes that have not been merged into the mainline tree, I just simply reverted the relevant commits (https://github.com/bbaa-bbaa/linux-intel-lts/tree/6bf2df6d263e101cbb9a2c996fa6de30ddd13e01/drivers/gpu/drm/i915). There may be some unexpected side effects.
Could you add drm.debug=0x19f log_buf_len=4M to the kernel cmdline to provide more logs for investigation?

After uninstalling desktop environment, I no more get these errors, but my Windows 10/11 VM randomly either works well or gets error 43 in device manager and nothing can be found in dmesg, and I can't find any solutions to fix it, so I temporarily disabled it.

Have you set the cpu = host?

Yes. This problem happens randomly. I have rebooted my VM for 10 times, 7 times works well and 3 times initialize failed with error 43.I found a solution:

  • Because Intel's driver fixes pciid to 02.0, when we use 02.1/2/3 and other sriov core graphics, it cannot be driven normally. Even if PCI-Express is checked in the direct sriov core graphics to show normal driving, some software will not work properly due to pciid, such as streaming media Jellyfin Emby, etc. cannot be hard-decoded and transcoded.
  • We need to specify the address of the direct core graphics in the virtual machine conf
  • nano /etc/pve/qemu-server/virtual machine serial number.conf
  • Add:
  • args: -set device.hostpci0.addr=02.0 -set device.hostpci0.x-igd-gms=0x2

but after trying it, GPU totally disappeared in my VM.

Can you try this instead:
qm set {VMID} --args "-cpu host,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt,hv-vendor-id=GenuineIntel"

@RaidenSummoner
Copy link

RaidenSummoner commented Oct 26, 2024 •
edited
Loading

But my host device won't stuck after applying your patch, is this trace a great concern?

I don't know. post_csc_lut seems is a struct about color management. Due to color management in the upstream Intel repository depends on DRM changes that have not been merged into the mainline tree, I just simply reverted the relevant commits (https://github.com/bbaa-bbaa/linux-intel-lts/tree/6bf2df6d263e101cbb9a2c996fa6de30ddd13e01/drivers/gpu/drm/i915). There may be some unexpected side effects.
Could you add drm.debug=0x19f log_buf_len=4M to the kernel cmdline to provide more logs for investigation?

After uninstalling desktop environment, I no more get these errors, but my Windows 10/11 VM randomly either works well or gets error 43 in device manager and nothing can be found in dmesg, and I can't find any solutions to fix it, so I temporarily disabled it.

Have you set the cpu = host?

Yes. This problem happens randomly. I have rebooted my VM for 10 times, 7 times works well and 3 times initialize failed with error 43.I found a solution:

  • Because Intel's driver fixes pciid to 02.0, when we use 02.1/2/3 and other sriov core graphics, it cannot be driven normally. Even if PCI-Express is checked in the direct sriov core graphics to show normal driving, some software will not work properly due to pciid, such as streaming media Jellyfin Emby, etc. cannot be hard-decoded and transcoded.
  • We need to specify the address of the direct core graphics in the virtual machine conf
  • nano /etc/pve/qemu-server/virtual machine serial number.conf
  • Add:
  • args: -set device.hostpci0.addr=02.0 -set device.hostpci0.x-igd-gms=0x2

but after trying it, GPU totally disappeared in my VM.

Can you try this instead: qm set {VMID} --args "-cpu host,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt,hv-vendor-id=GenuineIntel"

Thanks! :args -cpu hv-vendor-id=GenuineIntel seems to be worked for me with latest xe driver for Windows.

@bbaa-bbaa bbaa-bbaa mentioned this pull request Oct 27, 2024
Open
@johntdavis84
Copy link

johntdavis84 commented Oct 27, 2024 •
edited
Loading

What are the advantages of making this change?

I'm asking for a couple of reasons, as I anticipate these are issues others will have:

  1. It seems to make Windows VMs more difficult to work with? I've never had to manually edit my Windows VM conf file to get SR-IOV working. In fact, it's been easier to manage the guest-side drivers in Windows than in Linux.
  2. Kernel 6.5-based guests. I have a VM that depends on an Ubuntu fork that's stuck on the 6.5.0.x kernel. I'd request that if kernel 6.5 support is going to be removed, that the 6.5-based fork be in place before that. Will the 6.5-based fork still be maintained for future bug fixes/performance improvements?z

ETA: The latest SR-IOV related kernel commits from Intel suggest that iGPU SR-IOV support might hit in kernel 6.13. How much work would it be to maintain the current status quo for kernel support vs. re-basing, if we're that close to in-kernel official support that would (hopefully) be an easier, more stable alternative than this DKMS driver?

@bbaa-bbaa
Copy link
Contributor Author

bbaa-bbaa commented Oct 28, 2024 •
edited
Loading

What are the advantages of making this change?

The module based on 6.1 is too old, rebasing to a new branch is the simplest way to get upstream fixes.
We encountered issues similar to #186 and #204 with the older version of the module, and it's hard to pick out relevant fixes from the extensive patch set.

It seems to make Windows VMs more difficult to work with?

In my setup, modules based on branch 6.1 also require setting the vendor ID for the guest driver to work. (#8 (comment)) This might be related to the driver version on the guest side. If your vm works with older versions of the module, there should be no issues with the newer versions as well.

Will the 6.5-based fork still be maintained for future bug fixes/performance improvements.

In fact, the older version of the module is based on kernel 6.1. I currently don’t use kernels below version 6.8, and the 6.1-based branch may be maintained by other contributors.
Additionally, if have performance issues, please report to Intel upstream. I don't have the capability to fix upstream issues.

ETA: The latest SR-IOV related kernel commits from Intel suggest that iGPU SR-IOV support might hit in kernel 6.13. How much work would it be to maintain the current status quo for kernel support vs. re-basing.

Rebasing to a new branch is the simplest way to get upstream fixes for newer kernel.
My recommendation is to use the module based on kernel 6.1 for Linux versions 6.1–6.7, and the module based on kernel 6.6 for Linux versions 6.8–6.11. For kernel 6.6, you might also consider using Intel’s upstream kernel directly, which is more likely to receive first-party support. If SR-IOV support is eventually merged into the mainline kernel, using the mainline kernel would be the best choice.

@bbaa-bbaa bbaa-bbaa mentioned this pull request Nov 2, 2024
Closed
@bbaa-bbaa bbaa-bbaa mentioned this pull request Nov 3, 2024
Open
resiliencer added a commit to resiliencer/i915-sriov-dkms that referenced this pull request Nov 4, 2024
@resiliencer
Update:
4c37d85 
Source code had been synchronized with @Strongz repo,
but I had got some i915 errors during boot and init in dmesg.
So I had integrated @BBAA Pull Request strongtz#207 and it solved the problem.
Now everything works on linux kernel 6.11.2-zen.
@rb-andrade
Copy link

Has anyone tried this with Tiger Lake? I tried with i7-1165G7 with no success. I get code 43 on Windows. GuC firmware version 70.1.1 is being loaded instead of the latest one for some reason.

@resiliencer
Copy link

Has anyone tried this with Tiger Lake? I tried with i7-1165G7 with no success. I get code 43 on Windows. GuC firmware version 70.1.1 is being loaded instead of the latest one for some reason.

Just try https://github.com/resiliencer/i915-sriov-dkms#first-of-all-you-need-to-extract-intelgopdriverefi-from-your-bios
For me this solved the error number 43 issue for any VM with Windows OS.

@bbaa-bbaa
Copy link
Contributor Author

bbaa-bbaa commented Nov 12, 2024 •
edited
Loading

Has anyone tried this with Tiger Lake? I tried with i7-1165G7 with no success. I get code 43 on Windows. GuC firmware version 70.1.1 is being loaded instead of the latest one for some reason.

Tiger Lake does not support SR-IOV.
https://www.intel.com/content/www/us/en/support/articles/000093216/graphics/processor-graphics.html

@resiliencer
Copy link

resiliencer commented Nov 12, 2024 •
edited
Loading

I don't know if SR-IOV works or is supported on Tiger Lake, I haven't tested it, but at least I've seen this info:

Intel's response in the past:
https://community.intel.com/t5/Graphics/SR-IOV-support-for-intel-Iris-Xe-Graphics-on-i7-1165G7/m-p/1294037
Documentation that has not been updated for a long time:
https://open-iov.org/index.php/GPU_Support

Links with success stories with Tiger Lake:
https://forum.proxmox.com/threads/audio-is-same-iommu-group-as-ethernet-how-pass-through.128404/post-561804
https://dlworld.github.io/virtualization/2022/09/18/tigerlake-sriov/
#8 (comment)
#8 (comment)

And I Think before Windows or another Guest OS initializes the iGPU video driver, the Guest VM's UEFI at first must correctly initialize IntelGopDriver.efi. Missing that causes many problems everywhere(like err.code 43) on different intel generations.
#8 (comment)

Interesting that GuC/HuC firmware file names in dmesg on Raptor Lake have the tgl prefix:
[...] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/tgl_guc_70.bin version 70.29.2
[...] i915 0000:00:02.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/intel-linux/1421529-intel-begins-sorting-out-sr-iov-support-for-the-xe-kernel-graphics-driver?p=1421543#post1421543

Initially we plan to add SR-IOV functionality to the following SDV platforms
already supported by the Xe driver:

  • TGL (up to 7 VFs)
    ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
7 participants
@bbaa-bbaa @RaidenSummoner @admarty @johntdavis84 @rb-andrade @resiliencer @alapins