linux.git/drivers/gpu/drm/xe/xe_module.c, branch v7.2

drm/xe/guc: Hold device ref until queue teardown completes

2026-07-16T14:33:08+00:00

GuC exec queue destruction can run asynchronously. If the final device
put happens from a destroy worker, drmm cleanup can end up draining
the same workqueue and deadlock.

Hold a drm_device reference for the queue lifetime and drop it after
queue teardown completes. This keeps drmm cleanup from running while
async destroy work is still pending.

Move GuC destroy work to a module-lifetime Xe workqueue and flush it
on PCI remove so hot-unbind/rebind still waits for pending destroy work.

With queue-held device refs, guc_submit_sw_fini() cannot run with live
GuC IDs. Replace the fini wait with an assertion and remove the unused
fini_wq.

v2:
  - Rebase

v3:
  - Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt)
  - Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt)
  - Drop separate deferred drm_dev_put worker.
  - Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini().

v4:
  - Replace the guc_submit_sw_fini() wait with an assertion and remove
    the now-unused fini_wq. (sashiko)

v5:
  - Move destroy work to a module-lifetime Xe workqueue instead of
    system_dfl_wq. (Matt)
  - Flush the module-lifetime destroy workqueue during PCI remove to
    preserve the old device-remove wait semantics.

v6:
  - Keep SVM pagemap destroy work on the per-device destroy_wq to avoid
    letting it outlive the xe_device/drm_device. (Sashiko)
  - Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work
    can be queued from the reclaim path.

v7:
  - Drop the per-device xe->destroy_wq and use the module-level destroy WQ
    for SVM pagemap destroy as well. (Matt)
  - Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*()
    helpers because the WQ is no longer exec-queue specific. (Matt)

v8:
  - Rebase.

v9:
  - Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM
    destroy_wq because it can be queued from reclaim and embeds
    the dev_pagemap used by devres teardown. (Sashiko)
  - Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM
    from it.
  - Update the module-WQ kdoc to document the GuC/SVM split.

v10:
  - Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the
    workqueue allocation warning.

v11:
  - Drop the SVM pagemap destroy comment as it was revision-specific.
    (Thomas)

v12:
  - Rebase.

Fixes: 2d2be279f1ca ("drm/xe: fix UAF around queue destruction")
Cc: Thomas Hellström 
Cc: Rodrigo Vivi 
Cc: Himal Prasad Ghimiray 
Cc: Tejas Upadhyay 
Reviewed-by: Matthew Brost 
Signed-off-by: Arvind Yadav 
Link: https://patch.msgid.link/20260716062624.211396-1-arvind.yadav@intel.com
Signed-off-by: Tejas Upadhyay 
(cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)
Signed-off-by: Thomas Hellström

drm/xe: Don't expose display modparam if no display support

2026-02-26T12:44:55+00:00

With CONFIG_DRM_XE_DISPLAY=n the display support will be compiled
out, so exposing probe_display modparam is pointless.

Signed-off-by: Michal Wajdeczko 
Reviewed-by: Rodrigo Vivi 
Link: https://patch.msgid.link/20260216183240.1308-1-michal.wajdeczko@intel.com

drm/xe: Keep all defaults in single header

2026-02-03T10:58:26+00:00

We already have most of Xe defaults defined in xe_module.c,
where we use them for the modparam initializations, but some
were defined elsewhere, which breaks the consistency.

Introduce xe_defaults.h file, that will act as a placeholder
for all our default values, and can be used from other places.

Signed-off-by: Michal Wajdeczko 
Reviewed-by: Piotr Piórkowski 
Acked-by: Rodrigo Vivi 
Link: https://patch.msgid.link/20260121214218.2817-2-michal.wajdeczko@intel.com

drm/xe: Cleanup unused header includes

2026-01-15T15:05:04+00:00

clangd reports many "unused header" warnings throughout the Xe driver.
Start working to clean this up by removing unnecessary includes in our
.c files and/or replacing them with explicit includes of other headers
that were previously being included indirectly.

By far the most common offender here was unnecessary inclusion of
xe_gt.h.  That likely originates from the early days of xe.ko when
xe_mmio did not exist and all register accesses, including those
unrelated to GTs, were done with GT functions.

There's still a lot of additional #include cleanup that can be done in
the headers themselves; that will come as a followup series.

v2:
 - Squash the 79-patch series down to a single patch.  (MattB)

Reviewed-by: Matthew Brost 
Link: https://patch.msgid.link/20260115032803.4067824-2-matthew.d.roper@intel.com
Signed-off-by: Matt Roper

drm/xe: Validate wedged_mode parameter and define enum for modes

2026-01-08T21:07:07+00:00

Check correctness of the wedged_mode parameter input to ensure only
supported values are accepted. Additionally, replace magic numbers with
a clearly defined enum.

Signed-off-by: Lukasz Laguna 
Reviewed-by: Rodrigo Vivi 
Link: https://patch.msgid.link/20260107174741.29163-2-lukasz.laguna@intel.com
Signed-off-by: Rodrigo Vivi

drm/xe: Print module init abort code

2025-08-05T18:53:17+00:00

We should provide a hint to the user why the module refused to
load. This will also allow us to drop individual error messages
from init steps.

Signed-off-by: Michal Wajdeczko 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Lucas De Marchi 
Link: https://lore.kernel.org/r/20250731193339.179829-3-michal.wajdeczko@intel.com
Signed-off-by: Lucas De Marchi

drm/xe: Simplify module initialization code

2025-08-05T18:52:53+00:00

There is no need to have extra checks and WARN() in the helpers
as instead of an index of the entry with function pointers, we
can pass pointer to the entry which we prepare directly in the
main loop, that is guaranteed to be valid.

  add/remove: 0/0 grow/shrink: 0/4 up/down: 0/-180 (-180)
  Function                                     old     new   delta
  xe_exit                                      109      79     -30
  cleanup_module                               109      79     -30
  xe_init                                      248     188     -60
  init_module                                  248     188     -60
  Total: Before=2774145, After=2773965, chg -0.01%

Signed-off-by: Michal Wajdeczko 
Cc: Lucas De Marchi 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: John Harrison 
Reviewed-by: Lucas De Marchi 
Link: https://lore.kernel.org/r/20250731193339.179829-2-michal.wajdeczko@intel.com
Signed-off-by: Lucas De Marchi

drm/xe/pf: Enable SR-IOV PF mode by default

2025-07-23T18:49:48+00:00

We already claim official support for SR-IOV PF/VF modes on PTL
and BMG platforms, but by default we start the Xe driver on those
platforms in non-virtualized mode (native) since we still have
max_vfs modparam set to disable creation of the VFs.

It's time to let the Xe driver support SR-IOV PF mode by default.
We were already testing this on our CI, which was relying on the
patch that was enabling it for CONFIG_DRM_XE_DEBUG used by our CI.

Signed-off-by: Michal Wajdeczko 
Cc: Thomas Hellstrom 
Cc: Lucas De Marchi 
Cc: Rodrigo Vivi 
Reviewed-by: Lucas De Marchi 
Link: https://lore.kernel.org/r/20250722182618.30811-3-michal.wajdeczko@intel.com
Signed-off-by: Lucas De Marchi

drm/xe: Normalize default param values

2025-07-11T19:56:38+00:00

Document xe module params with the default values following a similar
strategy for all of them:

	1) Define a DEFAULT_* macro with the default value. When the
	   value can't be directly stringified, also define a *_STR
	   variant
	2) Use __stringify() or the _STR variant to make sure the
	   default value shows up in the param description

This allows us to show the correct default according to the
configuration. max_vfs for example was wrongly documented for
CONFIG_DRM_XE_DEBUG and svm_notifier_size didn't have its default
documented.

Reviewed-by: John Harrison 
Link: https://lore.kernel.org/r/20250626-guc-log-level-v3-1-c3ed8b452e91@intel.com
Signed-off-by: Lucas De Marchi

drm/xe: Annotate default for guc_log_level param

2025-06-17T19:21:55+00:00

Reword the parameter description so it's clear what's the default and
what are the verbose levels.

Reviewed-by: John Harrison 
Link: https://lore.kernel.org/r/20250613-guc-log-level-v2-2-cb84a63e49fe@intel.com
Signed-off-by: Lucas De Marchi