When host PF writes the logical configuration for the GUC PAGING engine,
the VF is meant to query it, and mirror it. Size of N means we have
paging logical index range [0, N-1], with N fewer normal copy engines.
Agreement is that PF will only spawn PAGING engines on NVL-S+, so this
should be zero on older platforms, where we should simply fall back to
the old behaviour.
v2 (Sashiko):
- We can't call use the guc_has_paging_engine() this early in the VF
code. With that just unconditionally do the query, if the GuC is new
enough and take the value as-is. With that drop the -1 special case and
just let the upper layers figure out the rest.
v3:
- Also update xe_guc_klv_key_to_string. (Michal)
- Add kernel-doc for xe_gt_sriov_vf_paging_engines(), plus other
tweaks. (Michal)
- Update with final GuC version.
v4:
- Just fallback to manual reserve when vf reported paging engines is
zero. Will revisit in the future.
v5 (Michal):
- Convert the assert to a full abort if we ever see non-zero GuC
paging engine count, on pre-nvl.
- Move the VF hunk in guc_has_paging_engine() here.
- Some small tweaks.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patch.msgid.link/20260626111520.487997-20-matthew.auld@intel.com
In the GuC backend, we need a different logical instance when referring
to the reserved paging engine. Under the hood, this is still just the
same physical BSC engine, however from the GuC POV this is actually
re-mapped to a separate GUC_PAGING_CLASS, with the logical index
starting from zero.
The idea is to not leak this into the upper layers, since this is GuC
version specific, so the changes here are purely on the GuC side.
No functional change.
v2:
- Add some kernel-doc to explain the usage.
- Move the implementation to guc.c
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20260626111520.487997-18-matthew.auld@intel.com
On newer platforms, the paging configuration is now configured by the PF
via the ADS object, where VF side should ensure that everything
configured as GUC_PAGING_CLASS is correctly mirrored on VF side. For
example PF could in theory reserve two BCS instances, and we expect VF
to mirror that.
With that move towards having a logical mask of all the paging engines,
and also generalise selecting those engines, based on the number of
paging engines. Also cache the first designated paging engine, which
will makes things a little cleaner here, and in later patches.
No functional changes for existing platforms.
v2 (Sashiko):
- Rework the loop slightly so that we don't needlessly check for the
paging engine, before we have correctly set the logical instance.
- Add a proper error return, if we encounter a bogus paging config.
Thinking ahead to VF where the config is defined by the PF, we
should just gracefully exit the probe sequence.
v3:
- Move paging_engines > copy_engines engines check to VF patch.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Francois Dugast <francois.dugast@intel.com>
Link: https://patch.msgid.link/20260626111520.487997-17-matthew.auld@intel.com
On newer platforms, the GuC has a new engine class which we need to use
to refer to the dedicated/reserved KMD BCS engine. With that, add the
plumbing in the GuC backend to support GUC_PAGING_CLASS and
GUC_CAPTURE_LIST_CLASS_PAGING.
Currently this is still turned off.
v2 (Daniele)
- Also add adjust the capture list for hpg, so we account for nvl-s.
- Move single paging engine assert to a more natural place.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20260626111520.487997-15-matthew.auld@intel.com
Rather than inferring the GuC engine class from the generic hw engine
class, pass in the hwe itself, which gives the complete view, like
instance etc. On future GuC versions, there is dedicated PAGING class to
identify the KMD reserved BCS engine, so we need more info here in order
to return the correct GuC specific engine class.
With this everything should now be using the new hwe based interface. No
functional changes.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20260626111520.487997-14-matthew.auld@intel.com
Currently in the lrc init flow on the ads side, we loop through each
generic engine class and convert that to the respective guc engine
class. However, with some upcoming changes, it will be better to go the
opposite way and loop through every guc engine class, and convert that
to the generic engine class.
This will be needed in an upcoming patch where we have a new guc engine
class that just matches up to the existing blitter/copy class, but needs
to be treated as a separate entity from the normal copy lrc, when
setting up the ADS.
This also reworks engine_enable_mask to operate on the guc_class, that
way we can easily filter out the PAGING vs normal BSC, when applicable.
As a bonus, this also gets rid of two xe_engine_class_to_guc_class()
users which will be helpful for the next patch.
No functional changes.
v2 (Daniele):
- Simplify fill_engine_enable_masks() to just loop over all guc
classes.
Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20260626111520.487997-13-matthew.auld@intel.com
Add support for the GuC uncorrectable local error G2H notification and
opt in to the feature when the submission ABI exposes it.
When the notification targets a known exec queue, treat it like an
engine reset request and route it through the existing timeout cleanup
path. This keeps the queue teardown, pending job cancellation and error
capture in one place instead of open-coding a parallel recovery flow.
Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20260706234353.3874355-1-zhanjun.dong@intel.com
The CT layer returns -ECANCELED regardless of whether cancellation
is due to a GT reset or a wedged device. Return -ENOTRECOVERABLE
on wedge so callers don't need xe_device_wedged() checks
to suppress spurious error logs.
Also document the return codes of xe_guc_ct_send() in kernel-doc form.
v2: Fix -ECANCELED description (Matt)
Signed-off-by: Sk Anirban <sk.anirban@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260624194618.2793571-5-sk.anirban@intel.com
When CONFIG_DRM_GPUSVM=n (e.g. um-allyesconfig), the only caller of
xe_pt_svm_userptr_notifier_lock() is compiled out, triggering:
drivers/gpu/drm/xe/xe_pt.c:1418:13: warning:
'xe_pt_svm_userptr_notifier_lock' defined but not used
[-Wunused-function]
The helpers cannot simply be removed in this case: the matching
xe_pt_svm_userptr_notifier_unlock() is also referenced from
xe_pt_update_ops_run(), which lives outside any DRM_GPUSVM ifdef and is
gated only at runtime by pt_update_ops->needs_svm_lock. The symbol must
exist in all builds.
Provide empty static inline stubs for !DRM_GPUSVM, matching the pattern
used by xe_svm_notifier_lock()/_unlock() in xe_svm.h.
Fixes: 80ccbd97ff ("drm/xe/userptr: Hold notifier_lock for write on inject test path")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202606302210.QqcLbOEN-lkp@intel.com/
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260630192221.2998168-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
xe_vm_madvise_ioctl() allocates madvise_range.vmas in get_vmas().
After get_vmas() succeeds with at least one VMA, error paths must go
through free_vmas so the array is released before the madvise details are
destroyed.
The L2 flush validation path added for PAT madvise rejects some
SVM/userptr ranges after get_vmas() has succeeded, but jumps directly to
madv_fini. This skips kfree(madvise_range.vmas), leaking the VMA array on
each failed ioctl.
Jump to free_vmas instead, matching the other validation failure paths
after get_vmas() has succeeded.
Fixes: 4f39a194d4 ("drm/xe/xe3p_lpg: Restrict UAPI to enable L2 flush optimization")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/20260708073422.725186-1-lgs201920130244@gmail.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Before arming a user job, xe_exec_ioctl() only added the VM's
dma-resv KERNEL slot as a dependency. That slot covers rebinds and
the kernel operations of the VM's private BOs, but not external BOs
(bo->vm == NULL), which carry their kernel operations (evictions,
moves, ...) in their own dma-resv KERNEL slot.
The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for
memory management operations that must complete before the BO or its
backing store may be used: any accessor is required to wait on the
KERNEL fences before touching the resv. By skipping the external BOs'
KERNEL slots, the exec path violated that contract and could schedule
a user job while a kernel operation on an external BO mapped by the VM
was still in flight, racing against it and potentially reading or
writing memory that was being moved.
Replace the VM-only dependency with an iteration over every object
locked by the exec, adding each object's KERNEL slot as a job
dependency. This covers the VM resv (rebinds and private BOs) as well
as every external BO, mirroring the drm_gpuvm_resv_add_fence() call
that later publishes the job fence to the same set of objects.
Long-running mode continues to skip this, as before.
Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: stable@vger.kernel.org
Assisted-by: GitHub_Copilot:claude-opus-4.8
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260702215805.4011228-1-matthew.brost@intel.com
On GMDID-based platforms, the driver needs to probe the hardware by
reading GMDID registers in order to identify the
graphics/media/display IPs that are present in the platform as well as
their stepping values.
Currently, xe_info_init() has such a probing logic, but that task
should be rather responsibility of xe_probe_info(). As such, move it
to the latter.
For pre-GMDID platforms, the IPs are identified via PCI devid and
revid fields, which is arguably also hardware dependent. So do the
same for those platforms.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-7-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
The platform-level step information depends on the PCI revid and, as
such, should be probed in xe_probe_info_early() instead of
xe_info_init_early(). Move the code accordingly.
Note that we currently only update probed_info->step.platform as part
of this change. We will deal with the other fields of
probed_info->step as a follow-up change, which will be tied to the
probing of graphics and media IPs.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-5-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Currently xe_step_platform_get() uses info fields from xe->info to
define the platform-level stepping value.
Because the platform-level stepping info depends on the PCI revid, it
should be defined as part of xe_probe_info_early() instead of being
directly probed inside xe_info_init_early().
Let's make sure that xe_step_platform_get() receives the necessary
data as parameters and does not depend on xe->info. That will allow
us to move the call up to xe_probe_info_early() in an upcoming change.
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-4-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
The xe_step_*_get() functions update the step directly in
xe->info.step and are called by functions xe_info_init_early() and
xe_info_init().
As the stepping info is something probed from the hardware (via PCI
revid and/or GMDID) and we want to move away from probing inside
xe_info_init*() functions, let's make xe_step_*_get() functions modify
a pointer to the step structure instead of modifying xe->info.step
directly: this will allow an upcoming change that will move those
function calls out of the info init functions and will pass a member
of struct xe_probed_info instead of xe->info.step.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-2-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Functions xe_info_init_early() and xe_info_init() currently probe some
information from the hardware while doing initialization of info
fields. Besides mixing responsibilities, another issue from this
approach is that kunit tests need to implement static stubs for the
probing part.
Let's prepare the ground to ensuring that those functions stop probing
the information from the hardware by creating the necessary framework
for extracting the probing bits out of them. Do that by creating a
new struct type called xe_probed_info and the functions responsible
for populating it.
In upcoming changes, we will gradually refactor the code so that all
info needed by xe_info_init_early() and xe_info_init() that is probed
from the hardware is passed to them via struct xe_probed_info.
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Violet Monti <violet.monti@intel.com>
Link: https://patch.msgid.link/20260609-xe-probe-info-v1-1-21e83e188e60@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
xe_vm_populate_pgtable() indexed the source PTE array (update->pt_entries)
by the per-call loop counter, assuming each call starts at the first entry
of the update. That holds for the CPU bind path
(xe_migrate_update_pgtables_cpu), which populates a whole update in a single
call, but not for the GPU bind path: write_pgtable() splits an update into
MAX_PTE_PER_SDI (510) sized MI_STORE_DATA_IMM chunks, invoking the populate
callback once per chunk with an advancing qword_ofs but a fresh command-
buffer destination pointer.
As a result, every chunk after the first re-read pt_entries from index 0
instead of from its true offset, so PTEs beyond the first 510 entries of a
single update were programmed with the wrong physical pages, shifting the
mapping by exactly MAX_PTE_PER_SDI pages.
This stayed latent because a single update only exceeds 510 qwords when a
large (e.g. 2M) region is bound as individual 4K PTEs rather than a single
huge-page entry, which happens when the backing store is sufficiently
fragmented. It was surfaced by the BO defrag path, which deliberately
rebinds such fragmented ranges via the GPU bind path, producing
deterministic data corruption offset by 510 pages.
Index pt_entries by the chunk's absolute offset relative to update->ofs so
both the CPU and GPU paths pick the correct entries.
Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: stable@vger.kernel.org
Assisted-by: GitHub_Copilot:claude-opus-4.8
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260702012434.3861171-1-matthew.brost@intel.com
Uncorrectable errors from different endpoints in the device are steered to
the USP(Upstream Switch Port) which is a PCI Advanced Error Reporting (AER)
Compliant device. Downgrade all the errors to non-fatal to prevent PCIe
bus driver from triggering a Secondary Bus Reset (SBR). This allows error
detection, containment and recovery in the driver.
The Uncorrectable Error Severity Register has the 'Uncorrectable
Internal Error Severity' set to fatal by default. Set this to
non-fatal and unmask the error.
Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Link: https://patch.msgid.link/20260629082802.3690896-10-riana.tauro@intel.com
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Add devres grouping to handle device resource cleanup during
PCI error recovery.
Secondary Bus Reset (SBR) is triggered by PCI core when the
error_detected/mmio_enabled callbacks return PCI_ERS_RESULT_NEED_RESET.
Once SBR is complete, the slot_reset callback is triggered. SBR wipes
out all device memory requiring XE KMD to perform a device removal and
reprobe.
Calling xe_pci_remove() alone does not free the devres allocated.
Since there are no exported functions to release all devres, group the
devres allocations and release the entire group during slot reset to
ensure proper cleanup.
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Link: https://patch.msgid.link/20260629082802.3690896-8-riana.tauro@intel.com
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Add error_detected, mmio_enabled, slot_reset and resume recovery callbacks
to handle PCIe Advanced Error Reporting (AER) errors.
For fatal errors, the device is wedged and becomes inaccessible. Return
PCI_ERS_RESULT_NEED_RESET from error_detected to request a Secondary
Bus Reset (SBR).
For non-fatal errors, return PCI_ERS_RESULT_CAN_RECOVER from
error_detected to trigger the mmio_enabled callback. In this callback, the
device is queried to determine the error cause and attempt recovery based
on the error type.
Once the secondary bus reset(SBR) is completed the slot_reset callback
cleanly removes and reprobe the device to restore functionality.
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Link: https://patch.msgid.link/20260629082802.3690896-7-riana.tauro@intel.com
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
During a page table walk for binding, xe_pt_stage_bind() explicitly
skips initializing the xe_res_cursor for purged BOs, treating them
similarly to NULL VMAs by only setting the cursor size.
However, xe_pt_hugepte_possible() and xe_pt_scan_64K() did not check
if the BO was purged before attempting to walk the cursor using
xe_res_dma() and xe_res_next(). Because the cursor was left
uninitialized for purged BOs, this falls through and triggers
warnings like:
WARNING: drivers/gpu/drm/xe/xe_res_cursor.h:274 at xe_res_next
Fix this by explicitly checking if the BO is purged in both
xe_pt_hugepte_possible() and xe_pt_scan_64K(), returning early just
as we do for NULL VMAs, avoiding the invalid cursor accesses entirely.
As a precaution, also zero-initialize the cursor in xe_pt_stage_bind()
to ensure we don't pass garbage data into the page table walkers
if we ever hit a similar edge case in the future.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8418
Fixes: ad9843aac9 ("drm/xe/madvise: Implement purgeable buffer object support")
Assisted-by: Copilot:gemini-3.1-pro-preview
Reported-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Arvind Yadav <arvind.yadav@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Tested-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Link: https://patch.msgid.link/20260625152054.450125-8-matthew.auld@intel.com
When a buffer object is purged, its ttm.resource is set to NULL via the
TTM pipeline gutting flow. However, the BO remains in the client's
object list until userspace explicitly closes the GEM handle. If memory
stats are queried during this time, accessing bo->ttm.resource->mem_type
will result in a NULL pointer dereference.
Fix this by safely skipping purged BOs in bo_meminfo, as they no longer
consume any memory.
User is getting NPD on device resume, and possible theory is that in
bo_move(), if we need to evict something to SYSTEM to save the CCS state,
but the BO is marked as dontneed, this won't trigger a move but will
nuke the pages, leaving us with a NULL bo resource. And the meminfo()
doesn't look ready to handle a NULL resource.
v2 (Sashiko):
- There could potentially be other cases where we might end up with a
NULL resource, so make this a general NULL check for now.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8419
Fixes: ad9843aac9 ("drm/xe/madvise: Implement purgeable buffer object support")
Assisted-by: Copilot:gemini-3.1-pro-preview
Reported-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Arvind Yadav <arvind.yadav@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Tested-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Link: https://patch.msgid.link/20260625152054.450125-6-matthew.auld@intel.com
During very early development of the Xe driver the force_execlist module
parameter could be used to exercise some parts of the driver in a
GuC-less manner. This was primarily intended to ensure that the driver
was being designed and developed with proper modularity and layering;
use of the GuC firmware has always been considered mandatory for any
real Xe driver operation. The "execlist" implementation in the driver
was never completed, and has further bitrotted over time to the point
where it hangs during execution of even the simplest IGT tests like
xe_exec_store now.
Drop the force_execlist parameter; it's broken and isn't going to get
fixed. In the (very unlikely) event that we decide to bring something
like this back in the future, it would need to be as a per-device
configfs setting rather than a driver-wide module parameter.
The "execlist" implementation is now dead code, so it will probably also
be removed sometime in the near future. There's a bit more general
refactoring we might want to do first before we take that step, so for
now we're just removing the module parameter.
Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260626-remove_execlists-v1-1-2584d8c4a6f2@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Xe must only add registers to the GT whitelist if they are listed in the
"Software Allowlist" section of the bspec. These registers have been
carefully reviewed by the architecture/security teams to ensure that
they are safe to whitelist from a security perspective. The list of
allowed registers changes from platform to platform, and it is not safe
to assume that a register is safe to whitelist on a new platform/IP just
because it was whitelisted on older ones. This means that whitelist
entries in the driver that used undefined upper bounds
(XE_RTP_END_VERSION_UNDEFINED) for their version ranges should always be
considered illegal since they could potentially open unexpected security
holes on future platforms. Add a kunit test to scan the whitelist RTP
table and ensure that all entries have well-defined upper bounds on IP
version ranges.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20260626-kunit_whitelist_bounds-v3-1-aedf0b3adab9@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
The error path in hw_engine_init() explicitly frees a BO allocated
with xe_managed_bo_create_pin_map() via xe_bo_unpin_map_no_vm().
Since the managed BO already has a devm cleanup action registered,
this causes a double-free when devm unwinds during probe failure.
Remove the explicit free and let devm handle it, consistent with
all other xe_managed_bo_create_pin_map() callers.
Fixes: 0e1a47fcab ("drm/xe: Add a helper for DRM device-lifetime BO create")
Assisted-by: Claude:claude-opus-4.6
Reviewed-by: Zongyao Bai <zongyao.bai@intel.com>
Link: https://patch.msgid.link/20260626210631.3887291-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
The local "finish" pointer in xe_vma_userptr_force_invalidate() is
unconditionally written before each read, so the static storage class
serves no purpose. Worse, it makes the variable a process-wide shared
slot: the function's per-VM asserts do not exclude concurrent callers
on different VMs, so two such callers can race on the slot and take
the wrong if (finish) branch.
The function is gated by CONFIG_DRM_XE_USERPTR_INVAL_INJECT
(developer/test option, default n), so production builds are
unaffected.
Drop the static.
Fixes: 18c4e53695 ("drm/xe/userptr: Convert invalidation to two-pass MMU notifier")
Assisted-by: Claude:claude-opus-4.7
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Zongyao Bai <zongyao.bai@intel.com>
Link: https://patch.msgid.link/20260625224452.3243231-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
When CONFIG_DRM_XE_USERPTR_INVAL_INJECT=y, xe_pt_svm_userptr_pre_commit()
runs vma_check_userptr() with the svm notifier_lock taken for read. The
test injection causes vma_check_userptr() to call
xe_vma_userptr_force_invalidate(), which feeds into
xe_vma_userptr_do_inval() with drm_gpusvm_ctx.in_notifier=true. That
flag tells drm_gpusvm_unmap_pages() the caller already holds
notifier_lock for write and only asserts the mode. Because the caller
actually holds it for read, the assertion fires:
WARNING: drivers/gpu/drm/drm_gpusvm.c:1669 at \
drm_gpusvm_unmap_pages+0xd4/0x130 [drm_gpusvm_helper]
Call Trace:
xe_vma_userptr_do_inval+0x40d/0xfd0 [xe]
xe_vma_userptr_invalidate_pass1+0x3e6/0x8d0 [xe]
xe_vma_userptr_force_invalidate+0xde/0x290 [xe]
vma_check_userptr.constprop.0+0x1c6/0x220 [xe]
xe_pt_svm_userptr_pre_commit+0x6a3/0xc60 [xe]
...
xe_vm_bind_ioctl+0x3a0a/0x4480 [xe]
Acquire notifier_lock for write in pre-commit when the inject Kconfig
is enabled, via new helpers xe_pt_svm_userptr_notifier_lock()/_unlock().
Rename xe_svm_assert_held_read() to
xe_svm_assert_held_read_or_inject_write() so it asserts the correct
mode under each build configuration. Production builds
(CONFIG_DRM_XE_USERPTR_INVAL_INJECT=n) keep the existing read-mode
behavior bit-for-bit.
Fixes: 9e97874148 ("drm/xe/userptr: replace xe_hmm with gpusvm")
Assisted-by: Claude:claude-opus-4.7
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Zongyao Bai <zongyao.bai@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260625215615.3016892-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Currently, xe_display_bo_framebuffer_init() unconditionally attempts to
apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB creation with
-EINVAL if the BO is already VM_BINDed.
However, for imported dma-bufs (ttm_bo_type_sg), this check doesn't seem
to make much sense since CPU caching policy is entirely controlled by
the exporter. Plus there is no place to set this flag, in the first
place. Also this is not rejected if not yet vm_binded, but that seems
arbitrary since setting or not setting FORCE_WC should a noop either
way, at this stage, and whether it is currently VM_BINDed makes no
difference.
Currently if we run an app and offload rendering to an external dGPU,
like NV or another xe device, the dma-buf passed back to the compositor
(igpu) will be an actual external import from xe pov, and it will be
missing FORCE_WC, and if the compositor side did a VM_BIND before
turning into it into an fb the whole thing gets rejected.
So it looks like we either need to reject outright, no matter what, or
this usecase is valid and we need to loosen the restriction for sg
buffers. Proposing here to loosen the restriction.
Assisted-by: Gemini:gemini-3.1-pro-preview
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919
Fixes: 44e694958b ("drm/xe/display: Implement display support")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Cc: <stable@vger.kernel.org> # v6.12+
Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260612170501.550816-2-matthew.auld@intel.com
Matthew Auld
Julia Filipchuk
Daniele Ceraolo Spurio
Zhanjun Dong
Sk Anirban
Shuicheng Lin
Guangshuo Li
Karthik Poosa
Rafael Passos
Anas Khan
Matthew Brost
Gustavo Sousa
Riana Tauro
Ashutosh Dixit
Raag Jadav
Michal Wajdeczko
Matt Roper