-
Notifications
You must be signed in to change notification settings - Fork 147
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.
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
Rebase the dkms module on the linux-intel-lts 6.6/linux branch #207
Conversation
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:
But my host device won't stuck after applying your patch, is this trace a great concern? |
I don't know. Could you add |
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. |
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:
but after trying it, GPU totally disappeared in my VM. |
Can you try this instead: |
Thanks! :args -cpu hv-vendor-id=GenuineIntel seems to be worked for me with latest xe driver for Windows. |
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:
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? |
The module based on 6.1 is too old, rebasing to a new branch is the simplest way to get upstream fixes.
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.
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.
Rebasing to a new branch is the simplest way to get upstream fixes for newer kernel. |
Add doc to set compile flags for Ubuntu and Debian
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.
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 |
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: Links with success stories with Tiger Lake: 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. Interesting that GuC/HuC firmware file names in dmesg on Raptor Lake have the tgl prefix:
|
* drm/i915: Do not attempt to load the GSC multiple times commit 59d3cfdd7f9655a0400ac453bf92199204f8b2a1 upstream. If the GSC FW fails to load the GSC HW hangs permanently; the only ways to recover it are FLR or D3cold entry, with the former only being supported on driver unload and the latter only on DGFX, for which we don't need to load the GSC. Therefore, if GSC fails to load there is no need to try again because the HW is stuck in the error state and the submission to load the FW would just hang the GSCCS. Note that, due to wa_14015076503, on MTL the GuC escalates all GSCCS hangs to full GT resets, which would trigger a new attempt to load the GSC FW in the post-reset HW re-init; this issue is also fixed by not attempting to load the GSC FW after an error. Fixes: 15bd4a67e914 ("drm/i915/gsc: GSC firmware loading") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v6.3+ Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240820215952.2290807-1-daniele.ceraolospurio@intel.com (cherry picked from commit 03ded4d432a1fb7bb6c44c5856d14115f6f6c3b9) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> * drm/i915/fence: Mark debug_fence_init_onstack() with __maybe_unused [ Upstream commit fcd9e8afd546f6ced378d078345a89bf346d065e ] When debug_fence_init_onstack() is unused (CONFIG_DRM_I915_SELFTEST=n), it prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: .../i915_sw_fence.c:97:20: error: unused function 'debug_fence_init_onstack' [-Werror,-Wunused-function] 97 | static inline void debug_fence_init_onstack(struct i915_sw_fence *fence) | ^~~~~~~~~~~~~~~~~~~~~~~~ Fix this by marking debug_fence_init_onstack() with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Fixes: 214707fc2ce0 ("drm/i915/selftests: Wrap a timer into a i915_sw_fence") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240829155950.1141978-2-andriy.shevchenko@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 5bf472058ffb43baf6a4cdfe1d7f58c4c194c688) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> * drm/i915/fence: Mark debug_fence_free() with __maybe_unused [ Upstream commit f99999536128b14b5d765a9982763b5134efdd79 ] When debug_fence_free() is unused (CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS=n), it prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: .../i915_sw_fence.c:118:20: error: unused function 'debug_fence_free' [-Werror,-Wunused-function] 118 | static inline void debug_fence_free(struct i915_sw_fence *fence) | ^~~~~~~~~~~~~~~~ Fix this by marking debug_fence_free() with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Fixes: fc1584059d6c ("drm/i915: Integrate i915_sw_fence with debugobjects") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240829155950.1141978-3-andriy.shevchenko@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 8be4dce5ea6f2368cc25edc71989c4690fa66964) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> * drm/i915/guc: prevent a possible int overflow in wq offsets [ Upstream commit d3d37f74683e2f16f2635ee265884f7ca69350ae ] It may be possible for the sum of the values derived from i915_ggtt_offset() and __get_parent_scratch_offset()/ i915_ggtt_offset() to go over the u32 limit before being assigned to wq offsets of u64 type. Mitigate these issues by expanding one of the right operands to u64 to avoid any overflow issues just in case. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: c2aa552ff09d ("drm/i915/guc: Add multi-lrc context registration") Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Link: https://patchwork.freedesktop.org/patch/msgid/20240725155925.14707-1-n.zhandarovich@fintech.ru Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 1f1c1bd56620b80ae407c5790743e17caad69cec) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Sasha Levin <sashal@kernel.org> * drm/i915/gem: fix bitwise and logical AND mixup commit 394b52462020b6cceff1f7f47fdebd03589574f3 upstream. CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND is an int, defaulting to 250. When the wakeref is non-zero, it's either -1 or a dynamically allocated pointer, depending on CONFIG_DRM_I915_DEBUG_RUNTIME_PM. It's likely that the code works by coincidence with the bitwise AND, but with CONFIG_DRM_I915_DEBUG_RUNTIME_PM=y, there's the off chance that the condition evaluates to false, and intel_wakeref_auto() doesn't get called. Switch to the intended logical AND. v2: Use != to avoid clang -Wconstant-logical-operand (Nathan) Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Nathan Chancellor <nathan@kernel.org> Cc: stable@vger.kernel.org # v6.1+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> # v1 Link: https://patchwork.freedesktop.org/patch/msgid/643cc0a4d12f47fd8403d42581e83b1e9c4543c7.1726680898.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 4c1bfe259ed1d2ade826f95d437e1c41b274df04) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> * drm/i915/hdcp: fix connector refcounting commit 4cc2718f621a6a57a02581125bb6d914ce74d23b upstream. We acquire a connector reference before scheduling an HDCP prop work, and expect the work function to release the reference. However, if the work was already queued, it won't be queued multiple times, and the reference is not dropped. Release the reference immediately if the work was already queued. Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing connectors") Cc: Sean Paul <seanpaul@chromium.org> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org # v5.10+ Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240924153022.2255299-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit abc0742c79bdb3b164eacab24aea0916d2ec1cb5) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --------- Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Co-authored-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Co-authored-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Co-authored-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Co-authored-by: Jani Nikula <jani.nikula@intel.com>
pick from 1da86618bdce301d23e89ecce92161f9d3b3c5e7
Test with Linux version 6.12.0-zen1-1-zen (linux-zen@archlinux)
Dropping this for anyone else who wanders into this thread.... |
…nt versions of the patchset Fix possible workqueue warnings
@RaidenSummoner Could you try this branch? |
I'll check it after finishing my college exams in a copule of weeks. |
pick from moetayuko/intel-gpu-i915-backports@24fff30 upstream: ff283a7182cbd652283d7b7fd5181a9d259939f9..e41e858ce16d85a60e10a8c9e04f86a2915530ea e41e858ce16d85a60e10a8c9e04f86a2915530ea drm/i915/mtl: Handle lut equal check for MTL degamma ab1ef80c8e74b660144e92d674b1fe1ba3450c4a drm/i915/mtl: Add legacy degamma lut support 093b7595e293f48d5ad896722293dd68d0786075 drm/i915/mtl: Add support for 24 bit precision DG LUT 56d4cba62ba67ec49019fcd13cfc0a270d87c894 drm/i915/mtl: Add check for 24 bit precision DG LUT 8d866c66114b7878497ebbd6e91579f2150efd98 drm/i915/color: Add checks for extended luts f7e432035547eac89801d6edabc8febc5f0234d2 drm: Add helper functions for extended LUT 6765c66426bd5e25d76af123b93ec9bfe7143547 drm: Add Client Cap for advance degamma mode 98b4cf4004adeb05a4b4e445f791807bec3a53b8 drm/i915/mtl: Attach degamma mode property d13eda747e737e12699d34f724666b87a909726b drm/i915/mtl: Add degamma lut range for 24 bit degamma LUT d9960911cb914e6f0c260ea7f3dc0a88bbaa2115 drm/i915/color: Use new helper function a2730f60bf25897a7cc866f774d2ce8d6c8bdc81 drm/color: Add pipe degamma mode property 9c398ddbf01fa3885b179a956bd183408ae532e3 drm/i915/xelpd: Enable plane gamma 7da61cd2518056f2d68276ad4ecad92b49b96c5a drm/i915/xelpd: Program Plane Gamma Registers 38a23653ddfda26b5c69bcdbbfa2fa5055183501 drm/i915/xelpd: Add register definitions for Plane Gamma 91e211e2a74ef40ae3e5ff4e7774870547cde6da drm/i915/xelpd: Define and Initialize Plane Gamma Lut range 228662a6a86d7d16aa0f9ea20e4ff11a6d893b6f drm: Add Plane Gamma Lut property ee76df2c1c0cb438d80dfd8f4031d2c249bffdd7 drm: Add Plane Gamma Mode property fd8f1cea8590dcc7f5f2a93f617fdbf5e543ea57 drm/i915/xelpd: Enable Plane CSC 3fae4f870e2fabcb7eecb36605808d2bf830fa5e drm: Add helper to attach Plane ctm property 52ca4dc2c13b14de92865e192c5cab2d315694c5 drm: Add Plane CTM property 35d977ac50a4a4d9420814b5b0fc85981d1eef7c drm/i915/xelpd: Load plane color luts from atomic flip a7be0033a1457f40a1361f5e53c3b451323ba4ce drm/i915/xelpd: Initialize plane color features 88e485068702559efee335bd756715a6a5013342 drm/i915/xelpd: Add plane color check to glk_plane_color_ctl 7c685da055ba5d3d1c533854cbc27e2994702082 drm/i915/xelpd: Program Plane Degamma Registers f0d4a02bcc142c386b29080159c0d14c28f89143 drm/i915/xelpd: Add color capabilities of SDR planes 24ed0d35c453afb5c93ce038a33d73f285071a24 drm/i915/xelpd: Enable plane color features af6b56192f73c7367efaad7453f0282087696901 drm/i915/xelpd: Add register definitions for Plane Degamma dec8f49885a5a53cffa0068a073018fac1bf5afc drm/i915/xelpd: Define Degamma Lut range struct for HDR planes 5bddb14b4c331155694b26405c713de7a28b686b drm: Add Plane Degamma Lut property 1fc3ba91e52ea98d9a494a00a160acfdad03f20d drm: Add Plane Degamma Mode property c4f2521b14292f292780ecb43588f47fb5ba9ba1 drm: Add Enhanced Gamma LUT precision structure e228413bc0a943c5c46533602f9934391fc8102a drm/i915/xelpd: Adjust gamma lut size for legacy 75ba29fef538a28042b5f343c6961017357133d6 drm/i915/xelpd: Enable XE_LPD Gamma Lut readout 3b850ab9a7eb677512dd31ab2d98ae75c84e0066 drm/i915/xelpd: logarithmic gamma enabled only with advance gamma mode 06a8a821371e147623e397dc978fa751eef40656 drm: Add Client Cap for advance gamma mode 2e5622438f8c87a5e3dd58f5374d8f5b79320a00 drm/i915/xelpd: Attach gamma mode property c12115088f707bd8090f94bb1bdc607afad810df drm/i915/xelpd: Add support for Logarithmic gamma mode 3ed97b9fcb330e56363062a50568ba3d574be3df drm/i915/xelpd: Define color lut range structure ff283a7182cbd652283d7b7fd5181a9d259939f9 drm: Add gamma mode property Signed-off-by: bbaa <bbaa@bbaa.fun>
Port the previously reverted XeLPD display related changes
Rebase the dkms module on the linux-intel-lts 6.6/linux branch
Based on lts-v6.6.63-linux-241126T173815Z
Test on kernel 6.12.4-zen1 with ArchLinux / 6.8.12-5-pve with Proxmox VE
Other versions may need more testing.
Required kernel version: 6.8 ~ 6.12
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.