summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-12-23drm/pagemap: Add a drm_pagemap cache and shrinkerThomas Hellström5-18/+613
Pagemaps are costly to set up and tear down, and they consume a lot of system memory for the struct pages. Ideally they should be created only when needed. Add a caching mechanism to allow doing just that: Create the drm_pagemaps when needed for migration. Keep them around to avoid destruction and re-creation latencies and destroy inactive/unused drm_pagemaps on memory pressure using a shrinker. Only add the helper functions. They will be hooked up to the xe driver in the upcoming patch. v2: - Add lockdep checking for drm_pagemap_put(). (Matt Brost) - Add a copyright notice. (Matt Brost) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> # For merging through drm-xe. Link: https://patch.msgid.link/20251219113320.183860-8-thomas.hellstrom@linux.intel.com
2025-12-23drm/pagemap, drm/xe: Manage drm_pagemap provider lifetimesThomas Hellström3-9/+117
If a device holds a reference on a foregin device's drm_pagemap, and a device unbind is executed on the foreign device, Typically that foreign device would evict its device-private pages and then continue its device-managed cleanup eventually releasing its drm device and possibly allow for module unload. However, since we're still holding a reference on a drm_pagemap, when that reference is released and the provider module is unloaded we'd execute out of undefined memory. Therefore keep a reference on the provider device and module until the last drm_pagemap reference is gone. Note that in theory, the drm_gpusvm_helper module may be unloaded as soon as the final module_put() of the provider driver module is executed, so we need to add a module_exit() function that waits for the work item executing the module_put() has completed. v2: - Better commit message (Matt Brost) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> # For merging through drm-xe. Link: https://patch.msgid.link/20251219113320.183860-7-thomas.hellstrom@linux.intel.com
2025-12-23drm/pagemap: Add a refcounted drm_pagemap backpointer to struct drm_pagemap_zddThomas Hellström1-2/+8
To be able to keep track of drm_pagemap usage, add a refcounted backpointer to struct drm_pagemap_zdd. This will keep the drm_pagemap reference count from dropping to zero as long as there are drm_pagemap pages present in a CPU address space. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> # For merging through drm-xe. Link: https://patch.msgid.link/20251219113320.183860-6-thomas.hellstrom@linux.intel.com
2025-12-23drm/pagemap, drm/xe: Add refcounting to struct drm_pagemapThomas Hellström5-9/+109
With the end goal of being able to free unused pagemaps and allocate them on demand, add a refcount to struct drm_pagemap, remove the xe embedded drm_pagemap, allocating and freeing it explicitly. v2: - Make the drm_pagemap pointer in drm_gpusvm_pages reference-counted. v3: - Call drm_pagemap_get() before drm_pagemap_put() in drm_gpusvm_pages (Himal Prasad Ghimiray) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v1 Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> # For merging through drm-xe. Link: https://patch.msgid.link/20251219113320.183860-5-thomas.hellstrom@linux.intel.com
2025-12-23drm/pagemap, drm/xe: Ensure that the devmem allocation is idle before useThomas Hellström5-26/+88
In situations where no system memory is migrated to devmem, and in upcoming patches where another GPU is performing the migration to the newly allocated devmem buffer, there is nothing to ensure any ongoing clear to the devmem allocation or async eviction from the devmem allocation is complete. Address that by passing a struct dma_fence down to the copy functions, and ensure it is waited for before migration is marked complete. v3: - New patch. v4: - Update the logic used for determining when to wait for the pre_migrate_fence. - Update the logic used for determining when to warn for the pre_migrate_fence since the scheduler fences apparently can signal out-of-order. v5: - Fix a UAF (CI) - Remove references to source P2P migration (Himal) - Put the pre_migrate_fence after migration. v6: - Pipeline the pre_migrate_fence dependency (Matt Brost) Fixes: c5b3eb5a906c ("drm/xe: Add GPUSVM device memory copy vfunc functions") Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.15+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> # For merging through drm-xe. Link: https://patch.msgid.link/20251219113320.183860-4-thomas.hellstrom@linux.intel.com
2025-12-23drm/pagemap: Remove some dead codeThomas Hellström1-13/+0
The page pointer can't be NULL. v5: - New patch. (Matt Brost) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> # For merging through drm-xe. Link: https://patch.msgid.link/20251219113320.183860-3-thomas.hellstrom@linux.intel.com
2025-12-23drm/xe/svm: Fix a debug printoutThomas Hellström1-1/+1
Avoid spamming the log with drm_info(). Use drm_dbg() instead. Fixes: cc795e041034 ("drm/xe/svm: Make xe_svm_range_needs_migrate_to_vram() public") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: <stable@vger.kernel.org> # v6.17+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20251219113320.183860-2-thomas.hellstrom@linux.intel.com
2025-12-22drm/xe/pf: Add debugfs to set EQ and PT for scheduler groupsDaniele Ceraolo Spurio1-1/+111
Debugfs files are added to allow a user to provide a comma-separated list of values to assign to each group for each VF. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-26-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Add functions to set preempt timeouts for each groupDaniele Ceraolo Spurio4-1/+114
The KLV to set the preemption timeout for each groups works the exact same way as the one for the exec quantums, so we add similar functions. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-25-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Add functions to set exec quantums for each groupDaniele Ceraolo Spurio4-5/+181
The GuC has a new dedicated KLV to set the EQs for the groups. The GuC always sets the EQs for all the groups (even the ones not enabled). If we provide fewer values than the max number of groups (8), the GuC will set the remaining ones to 0 (infinity). Note that the new KLV can be used even when groups are disabled (as the GuC always consider group0 to be active), so we can use it when encoding the SRIOV config. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-24-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Prep for multiple exec quantums and preemption timeoutsDaniele Ceraolo Spurio3-10/+28
Each scheduler group can be independently configured with its own exec quantum and preemption timeouts. The existing KLVs to configure those parameters will apply the value to all groups (even if they're not enabled at the moment). When scheduler groups are disabled, the GuC uses the values from Group 0. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-23-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Add debugfs with scheduler groups informationDaniele Ceraolo Spurio1-0/+59
Under a new subfolder, an entry is created for each group to list the engines assigned to them. We create enough entries for each possible group, with the disabled groups just returning an empty list. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-22-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Add debugfs to enable scheduler groupsDaniele Ceraolo Spurio1-0/+126
Reading the debugfs file lists the available configurations by name. Writing the name of a configuration to the file will enable it. Note that while this debugfs is PF-only, follow up patches will add some debugfs files that are applicable to VF as well, so the function accepts a vfid parameter to be ready for that. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-21-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/vf: Check if scheduler groups are enabledDaniele Ceraolo Spurio6-0/+83
VF can check if PF has enabled scheduler groups with a dedicated KLV query. If scheduler groups are enabled, MLRC queue registrations are forbidden. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-20-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Scheduler groups are incompatible with multi-lrcDaniele Ceraolo Spurio7-0/+93
Since engines in the same class can be divided across multiple groups, the GuC does not allow scheduler groups to be active if there are multi-lrc contexts. This means that: 1) if a MLRC context is registered when we enable scheduler groups, the GuC will silently ignore the configuration 2) if a MLRC context is registered after scheduler groups are enabled, the GuC will disable the groups and generate an adverse event. The expectation is that the admin will ensure that all apps that use MLRC on PF have been terminated before scheduler groups are created. A check is added anyway to make sure we don't still have contexts waiting to be cleaned up laying around. A check is also added at queue creation time to block MLRC queue creation if scheduler groups have been enabled. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-19-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Add support for enabling scheduler groupsDaniele Ceraolo Spurio5-0/+190
Scheduler groups are enabled by sending a specific policy configuration KLV to the GuC. We don't allow changing this policy if there are VF active, since the expectation is that the VF will only check if the feature is enabled during driver initialization. While the GuC interface supports a maximum of 8 groups, the actual number of groups that can be enabled can be lower than that and can be different on different devices. For now, all devices support up to 2 groups, so we check that we do not have more groups than that. The functions added by this patch will be used by sysfs/debugfs, coming in follow up patches. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-18-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/pf: Initialize scheduler groupsDaniele Ceraolo Spurio6-0/+198
Scheduler groups (a.k.a. Engine Groups Scheduling, or EGS) is a GuC feature that allows the driver to define groups of engines that are independently scheduled across VFs, which allows different VFs to be active on the HW at the same time on different groups. The feature is available for BMG and newer HW starting on GuC 70.53.0, but some required fixes have been added to GuC 70.55.1. This is intended for specific scenarios where the admin knows that the VFs are not going to fully utilize the HW and therefore assigning all of it to a single VF would lead to part of it being permanently idle. We do not allow the admin to decide how to divide the engines across groups, but we instead support specific configurations that are designed for specific use-cases. During PF initialization we detect which configurations are possible on a given GT and create the relevant groups. Since the GuC expect a mask for each class for each group, that is what we save when we init the configs. Right now we only have one use-case on the media GT. If the VFs are running a frame render + encoding at a not-too-high resolution (e.g. 1080@30fps) the render can produce frames faster than the video engine can encode them, which means that the maximum number of parallel VFs is limited by the VCS bandwidth. Since our products can have multiple VCS engines, allowing multiple VFs to be active on the different VCS engines at the same time allows us to run more parallel VFs on the same HW. Given that engines in the same media slice share some resources (e.g. SFC), we assign each media slice to a different scheduling group. We refer to this configuration as "media_slices", given that each slice gets its own group. Since upcoming products have a different number of video engines per-slice, for now we limit the media_slices mode to BMG, but we expect to add support for newer HW soon. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-17-daniele.ceraolospurio@intel.com
2025-12-22drm/gt/guc: extract scheduler-related defines from guc_fwif.hDaniele Ceraolo Spurio4-54/+67
Some upcoming KLVs are sized based on the engine counts, so we need those defines to be moved to a separate file to include them from guc_klv_abi.h (which is already included by guc_fwif.h). Instead of moving just the engine-related defines, it is cleaner to move all scheduler-related defines (i.e., everything engine or context related). Note that the legacy GuC defines have not been moved and have instead been dropped because Xe doesn't support any GuC old enough to still use them. While at it, struct guc_ctxt_registration_info has been moved to guc_submit.c since it doesn't come from the GuC specs (we added it to make things simpler in our code). Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-16-daniele.ceraolospurio@intel.com
2025-12-22drm/xe/gt: Add engine masks for each classDaniele Ceraolo Spurio5-8/+15
Follow up patches will need the engine masks for VCS and VECS engines. Since we already have a macro for the CCS engines, just extend the same approach to all classes. To avoid confusion with the XE_HW_ENGINE_*_MASK masks, the new macros use the _INSTANCES suffix instead. For consistency, rename CCS_MASK to CCS_INSTANCES as well. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20251218223846.1146344-15-daniele.ceraolospurio@intel.com
2025-12-19drm/xe: Print GuC queue submission state on engine resetMatthew Brost1-2/+3
Print the GuC queue submission state when an engine reset occurs, as this provides clues about the cause of the reset. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251218224546.4057424-1-matthew.brost@intel.com
2025-12-19drm/xe: Increase log level for unhandled page faultsMatthew Brost2-24/+24
Set the kernel log level for unhandled page faults to match the log level (info) for engine resets. Currently, dmesg output can be confusing because it shows an engine reset without indicating the page fault that caused it. Without this change, the GuC log must be examined to determine the source of the engine reset. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20251218223745.4045207-1-matthew.brost@intel.com
2025-12-19drm/xe/xe_survivability: Add index bound checkRiana Tauro1-3/+7
Fix static analysis tool reported issue. Add index bound check before accessing info array to prevent out of bound. Fixes: f4e9fc967afd ("drm/xe/xe_survivability: Redesign survivability mode") Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251219105224.871930-6-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-19drm/xe/xe_survivability: Use static for survivability info attributesRiana Tauro1-9/+9
Fix sparse warnings. Use static for survivability info attributes. Fixes: f4e9fc967afd ("drm/xe/xe_survivability: Redesign survivability mode") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512101919.G12cuhBJ-lkp@intel.com/ Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251219105224.871930-5-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-19drm/xe/pmu: Replace sprintf() with sysfs_emit()Madhur Kumar1-1/+1
Replace sprintf() calls with sysfs_emit() to follow current kernel coding standards. sysfs_emit() is the preferred method for formatting sysfs output as it provides better bounds checking and is more secure. Signed-off-by: Madhur Kumar <madhurkumar004@gmail.com> Link: https://patch.msgid.link/20251214083659.2412218-1-madhurkumar004@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo adjusted commit message while pushing it]
2025-12-19Merge drm/drm-next into drm-xe-nextThomas Hellström10864-167997/+545722
Backmerging to bring in 6.19-rc1. An important upstream bugfix and to help unblock PTL CI. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-12-19drm/xe: Fix documentation heading levels in xe_guc_pc.cSwaraj Gaikwad1-2/+2
Sphinx reports htmldocs warnings: Documentation/gpu/xe/xe_firmware:31: ./drivers/gpu/drm/xe/xe_guc_pc.c:76: ERROR: A level 2 section cannot be used here. Documentation/gpu/xe/xe_firmware:31: ./drivers/gpu/drm/xe/xe_guc_pc.c:87: ERROR: A level 2 section cannot be used here. The xe_guc_pc.c documentation is included inside xe_firmware.rst. The headers in the C file currently use '=' underlines, which conflict with the parent document's section levels. Fix this by demoting "Frequency management" and "Render-C States" headers from '=' to '-' to correctly nest them as subsections. Build environment: Python 3.13.7 Sphinx 8.2.3 docutils 0.22.3 Signed-off-by: Swaraj Gaikwad <swarajgaikwad1925@gmail.com> Link: https://patch.msgid.link/20251209094836.18589-1-swarajgaikwad1925@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-19drm/xe/xe_survivability: Remove unused indexRiana Tauro1-11/+4
Remove unused index variable and fix for loop. Fixes: f4e9fc967afd ("drm/xe/xe_survivability: Redesign survivability mode") Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/intel-xe/20251210075757.GA1206705@ax162/ Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251218105151.586575-5-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-19drm/xe/nvm: enable cri platformAlexander Usyskin2-11/+24
Mark CRI as one that have the CSC NVM device. Update the writable override flow to take the information from the scratch register for CRI. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20251216111034.3093507-1-alexander.usyskin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-18drm/xe: Drop preempt-fences when destroying imported dma-bufs.Thomas Hellström1-11/+4
When imported dma-bufs are destroyed, TTM is not fully individualizing the dma-resv, but it *is* copying the fences that need to be waited for before declaring idle. So in the case where the bo->resv != bo->_resv we can still drop the preempt-fences, but make sure we do that on bo->_resv which contains the fence-pointer copy. In the case where the copying fails, bo->_resv will typically not contain any fences pointers at all, so there will be nothing to drop. In that case, TTM would have ensured all fences that would have been copied are signaled, including any remaining preempt fences. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Fixes: fa0af721bd1f ("drm/ttm: test private resv obj on release/destroy") Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Tested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251217093441.5073-1-thomas.hellstrom@linux.intel.com
2025-12-18drm/xe/eustall: Disallow 0 EU stall property valuesAshutosh Dixit1-1/+1
An EU stall property value of 0 is invalid and will cause a NPD. Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6453 Fixes: 1537ec85ebd7 ("drm/xe/uapi: Introduce API for EU stall sampling") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patch.msgid.link/20251212061850.1565459-4-ashutosh.dixit@intel.com
2025-12-18drm/xe/oa: Disallow 0 OA property valuesAshutosh Dixit1-1/+1
An OA property value of 0 is invalid and will cause a NPD. Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6452 Fixes: cc4e6994d5a2 ("drm/xe/oa: Move functions up so they can be reused for config ioctl") Cc: stable@vger.kernel.org Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patch.msgid.link/20251212061850.1565459-3-ashutosh.dixit@intel.com
2025-12-18drm/xe/oa: Move default oa unit assignment earlier during stream openAshutosh Dixit1-4/+4
De-referencing param.oa_unit, when an OA unit id is not provided during stream open, results in NPD below. Oops: general protection fault, probably for non-canonical address... KASAN: null-ptr-deref in range... RIP: 0010:xe_oa_stream_open_ioctl+0x169/0x38a0 xe_observation_ioctl+0x19f/0x270 drm_ioctl_kernel+0x1f4/0x410 Fix this by moving default oa unit assignment before the dereference. Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6840 Fixes: c7e269aa565f ("drm/xe/oa: Allow exec_queue's to be specified only for OAG OA unit") Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Link: https://patch.msgid.link/20251212061850.1565459-2-ashutosh.dixit@intel.com
2025-12-18drm/xe/pf: Add handling for MLRC adverse event thresholdDaniele Ceraolo Spurio2-0/+10
Since it is illegal to register a MLRC context when scheduler groups are enabled, the GuC consider the VF doing so as an adverse event. Like for other adverse event, there is a threshold for how many times the event can happen before the GuC throws an error, which we need to add support for. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251216214902.1429-5-michal.wajdeczko@intel.com
2025-12-18drm/xe/pf: Prepare for new threshold KLVsMichal Wajdeczko3-10/+23
We want to extend our macro-based KLV list definitions with new information about the version from which given KLV is supported. Prepare our code generators to emit dedicated version check if a KLV was defined with the version information. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251216214902.1429-4-michal.wajdeczko@intel.com
2025-12-18drm/xe/guc: Introduce GUC_FIRMWARE_VER_AT_LEAST helperMichal Wajdeczko3-3/+24
There are already few places in the code where we need to check GuC firmware version. Wrap existing raw conditions into a named helper macro to make it clear and avoid explicit call of the MAKE_GUC_VER. Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251216214902.1429-3-michal.wajdeczko@intel.com
2025-12-18drm/xe: Introduce IF_ARGS macro utilityMichal Wajdeczko2-0/+81
We want to extend our macro-based KLV list definitions with new information about the version from which given KLV is supported. Add utility IF_ARGS macro that can be used in code generators to emit different code based on the presence of additional arguments. Introduce macro itself and extend our kunit tests to cover it. We will use this macro in next patch. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251217224018.3490-1-michal.wajdeczko@intel.com
2025-12-18drm/xe: Fix NULL pointer dereference in xe_exec_ioctlTapani Pälli1-6/+4
Helper function xe_sync_needs_wait expects sync->fence when accessing flags, patch makes sure we call only when sync->fence exists. v2: move null checking to xe_sync_needs_wait and make xe_sync_entry_wait utilize this helper (Matthew Auld) v3: further simplify code (Matthew Auld) Fixes NULL pointer dereference seen with Vulkan workloads: [ 118.410401] RIP: 0010:xe_sync_needs_wait+0x27/0x50 [xe] Fixes: 4ac9048d0501 ("drm/xe: Wait on in-syncs when swicthing to dma-fence mode") Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251217132412.435755-1-tapani.palli@intel.com
2025-12-17MAINTAINERS: Update Xe driver maintainersRodrigo Vivi1-0/+1
Add Matt Brost, one of the Xe driver creators, as maintainer. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Acked-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251204193403.930328-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-12-17drm/xe/xe_sriov_vfio: Fix return value in xe_sriov_vfio_migration_supported()Dan Carpenter1-1/+1
The xe_sriov_vfio_migration_supported() function is type bool so returning -EPERM means returning true. Return false instead. Fixes: 17f22465c5a5 ("drm/xe/pf: Export helpers for VFIO") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/aTLEZ4g-FD-iMQ2V@stanley.mountain Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-12-17drm/xe/vf: fix return type in vf_migration_init_late()Dan Carpenter1-1/+1
The vf_migration_init_late() function is supposed to return zero on success and negative error codes on failure. The error code eventually gets propagated back to the probe() function and returned. The problem is it's declared as type bool so it returns true on error. Change it to type int instead. Fixes: 2e2dab20dd66 ("drm/xe/vf: Enable VF migration only on supported GuC versions") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/aTK9pwJ_roc8vpDi@stanley.mountain Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
2025-12-17drm/xe/oa: Always set OAG_OAGLBCTXCTRL_COUNTER_RESUMEAshutosh Dixit1-3/+4
Reports can be written out to the OA buffer using ways other than periodic sampling. These include mmio trigger and context switches. To support these use cases, when periodic sampling is not enabled, OAG_OAGLBCTXCTRL_COUNTER_RESUME must be set. Fixes: 1db9a9dc90ae ("drm/xe/oa: OA stream initialization (OAG)") Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20251205212613.826224-4-ashutosh.dixit@intel.com
2025-12-17drm/xe/rtp: Whitelist OAMERT MMIO trigger registersAshutosh Dixit1-0/+19
Whitelist OAMERT registers to enable userspace to execute MMIO triggers on OAMERT units. Registers are whitelisted for compute and copy class engines. Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20251205212613.826224-3-ashutosh.dixit@intel.com
2025-12-17drm/xe/oa/uapi: Expose MERT OA unitAshutosh Dixit3-3/+46
A MERT OA unit is available in the SoC on some platforms. Add support for this OA unit and expose it to userspace. The MERT OA unit does not have any HW engines attached, but is otherwise similar to an OAM unit. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20251205212613.826224-2-ashutosh.dixit@intel.com
2025-12-16drm/xe: Add more GT stats around pagefault mode switch flowsMatthew Brost3-0/+30
Add GT stats to measure the time spent switching between pagefault mode and dma-fence mode. Also add a GT stat to indicate when pagefault suspend is skipped because the system is idle. These metrics will help profile pagefault workloads while 3D and display are enabled. v2: - Use GT stats helper functions (Francois) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20251212182847.1683222-8-matthew.brost@intel.com
2025-12-16drm/xe: Add GT stats ktime helpersMatthew Brost2-20/+41
Normalize GT stats that record execution periods in code paths by adding helpers to perform the ktime calculation. Use these helpers in the SVM code. Suggested-by: Francois Dugast <francois.dugast@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-7-matthew.brost@intel.com
2025-12-16drm/xe: Wait on in-syncs when swicthing to dma-fence modeMatthew Brost5-11/+87
If a dma-fence submission has in-fences and pagefault queues are running work, there is little incentive to kick the pagefault queues off the hardware until the dma-fence submission is ready to run. Therefore, wait on the in-fences of the dma-fence submission before removing the pagefault queues from the hardware. v2: - Fix kernel doc (CI) - Don't wait under lock (Thomas) - Make wait interruptable Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-6-matthew.brost@intel.com
2025-12-16drm/xe: Skip exec queue schedule toggle if queue is idle during suspendMatthew Brost3-4/+70
If an exec queue is idle, there is no need to issue a schedule disable to the GuC when suspending the queue’s execution. Opportunistically skip this step if the queue is idle and not a parallel queue. Parallel queues must have their scheduling state flipped in the GuC due to limitations in how submission is implemented in run_job(). Also if all pagefault queues can skip the schedule disable during a switch to dma-fence mode, do not schedule a resume for the pagefault queues after the next submission. v2: - Don't touch the LRC tail is queue is suspended but enabled in run_job (CI) Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-5-matthew.brost@intel.com
2025-12-16drm/xe: Add debugfs knobs to control long running workload timeslicingMatthew Brost4-2/+83
Add debugfs knobs to control timeslicing for long-running workloads, allowing quick tuning of values when running benchmarks. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-4-matthew.brost@intel.com
2025-12-16drm/xe: Use usleep_range for accurate long-running workload timeslicingMatthew Brost1-1/+19
msleep is not very accurate in terms of how long it actually sleeps, whereas usleep_range is precise. Replace the timeslice sleep for long-running workloads with the more accurate usleep_range to avoid jitter if the sleep period is less than 20ms. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-3-matthew.brost@intel.com
2025-12-16drm/xe: Adjust long-running workload timeslices to reasonable valuesMatthew Brost2-2/+5
A 10ms timeslice for long-running workloads is far too long and causes significant jitter in benchmarks when the system is shared. Adjust the value to 5ms for preempt-fencing VMs, as the resume step there is quite costly as memory is moved around, and set it to zero for pagefault VMs, since switching back to pagefault mode after dma-fence mode is relatively fast. Also change min_run_period_ms to 'unsiged int' type rather than 's64' as only positive values make sense. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251212182847.1683222-2-matthew.brost@intel.com