kernel/linux.git/drivers/gpu/drm/xe/xe_query.c, branch linux-7.1.y

drm/xe/madvise: Enable purgeable buffer object IOCTL support

2026-03-27T02:59:53+00:00

Hook the madvise_purgeable() handler into the madvise IOCTL now that all supporting infrastructure is complete: - Core purge implementation (patch 3) - BO state tracking and helpers (patches 1-2) - Per-VMA purgeable state tracking (patch 6) - Shrinker integration for memory reclamation (patch 10) This final patch enables userspace to use the DRM_XE_VMA_ATTR_PURGEABLE_STATE madvise type to mark buffers as WILLNEED/DONTNEED and receive the retained status indicating whether buffers were purged. The feature was kept disabled in earlier patches to maintain bisectability and ensure all components are in place before exposing to userspace. Userspace can detect kernel support for purgeable BOs by checking the DRM_XE_QUERY_CONFIG_FLAG_HAS_PURGING_SUPPORT flag in the query_config response. Suggested-by: Matthew Brost Cc: Matthew Brost Reviewed-by: Thomas Hellström Signed-off-by: Himal Prasad Ghimiray Signed-off-by: Arvind Yadav Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260326130843.3545241-12-arvind.yadav@intel.com

drm/xe: Allow per queue programming of COMMON_SLICE_CHICKEN3 bit13

2026-03-10T13:45:10+00:00

Similar to i915's commit cebc13de7e704b1355bea208a9f9cdb042c74588 ("drm/i915: Whitelist COMMON_SLICE_CHICKEN3 for UMD access"), except that instead of putting the register on the allowlist for UMD to program, the KMD is doing the programming at context initialization based on a queue creation flag. This is a recommended tuning setting for both gen12 and Xe_HP platforms. If a render queue is created with DRM_XE_EXEC_QUEUE_SET_STATE_CACHE_PERF_FIX, COMMON_SLICE_CHICKEN3 will be programmed at initialization to enable the render color cache to key with BTP+BTI (binding table pool + binding table entry) instead of just BTI (binding table entry). This enables the UMD to avoid emitting render-target-cache-flush + stall-at-pixel-scoreboard every time a binding table entry pointing to a render target is changed. v2: Use xe_lrc_write_ring() v3: Update xe_query.c to report availability v4: Rename defines to add DISABLE_ v5: update commit message v6: rebase Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39982 Bspec: 73993, 73994, 72161, 31870, 68331 Acked-by: Rodrigo Vivi Reviewed-by: José Roberto de Souza Signed-off-by: Lionel Landwerlin Signed-off-by: José Roberto de Souza Link: https://patch.msgid.link/20260306075504.1288676-1-lionel.g.landwerlin@intel.com

drm/xe/query: Fix topology query pointer advance

2026-02-02T18:09:48+00:00

The topology query helper advanced the user pointer by the size of the pointer, not the size of the structure. This can misalign the output blob and corrupt the following mask. Fix the increment to use sizeof(*topo). There is no issue currently, as sizeof(*topo) happens to be equal to sizeof(topo) on 64-bit systems (both evaluate to 8 bytes). Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Shuicheng Lin Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260130043907.465128-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper

drm/xe/xe_query: Remove check for gt

2026-01-15T20:57:25+00:00

There's no need to check a userspace-provided GT ID (which may come from any tile) against the number of GTs that can be present on a single tile. The xe_device_get_gt() lookup already checks that the GT ID passed is valid for the current device.(Matt Roper) Signed-off-by: Nakshtra Goyal Reviewed-by: Matt Roper Link: https://patch.msgid.link/20260113091928.67446-1-nakshtra.goyal@intel.com Signed-off-by: Matt Roper

drm/xe/oa/uapi: Add gt_id to struct drm_xe_oa_unit

2025-12-04T21:33:20+00:00

gt_id was previously omitted from 'struct drm_xe_oa_unit' because it could be determine from hwe's attached to the OA unit. However, we now have OA units which don't have any hwe's attached to them. Hence add gt_id to 'struct drm_xe_oa_unit' in order to provide this needed information to userspace. Signed-off-by: Ashutosh Dixit Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20251202025115.373546-3-ashutosh.dixit@intel.com

drm/xe/uapi: Add NO_COMPRESSION BO flag and query capability

2025-12-04T11:31:11+00:00

Introduce DRM_XE_GEM_CREATE_FLAG_NO_COMPRESSION to let userspace opt out of CCS compression on a per-BO basis. When set, the driver maps this to XE_BO_FLAG_NO_COMPRESSION, skips CCS metadata allocation/clearing, and rejects compressed PAT indices at vm_bind. This avoids extra memory ops and manual CCS state handling for buffers. To allow userspace to detect at runtime whether the kernel supports this feature, add DRM_XE_QUERY_CONFIG_FLAG_HAS_NO_COMPRESSION_HINT and expose it via query_config() on Xe2+ platforms. Mesa PR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38425 IGT PR: https://patchwork.freedesktop.org/patch/685180/ v2 - Changed error code from -EINVAL to -EOPNOTSUPP for unsupported flag usage on pre-Xe2 platforms - Fixed checkpatch warning in xe_vm.c - Fixed kernel-doc formatting in xe_drm.h v3 - Rebase - Updated commit title and description - Added UAPI for DRM_XE_QUERY_CONFIG_FLAG_HAS_NO_COMPRESSION_HINT and exposed it via query_config() v4 - Rebase v5 - Included Mesa PR and IGT PR in the commit description - Used xe_pat_index_get_comp_en() to extract the compression v6 - Added XE_IOCTL_DBG() checks for argument validation Suggested-by: Matthew Auld Suggested-by: José Roberto de Souza Acked-by: José Roberto de Souza Reviewed-by: Matthew Auld Signed-off-by: Sanjay Yadav Signed-off-by: Matthew Auld Link: https://patch.msgid.link/20251204040402.2692921-2-sanjay.kumar.yadav@intel.com

drm/xe/query: Use scope-based forcewake

2025-11-19T19:58:58+00:00

Use scope-based forcewake handling for consistency with other parts of the driver. Reviewed-by: Gustavo Sousa Link: https://patch.msgid.link/20251118164338.3572146-47-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe/query: Report hwconfig size as 0 if primary GT is disabled

2025-10-14T14:44:58+00:00

The hwconfig table is part of the primary GT's GuC firmware. If the primary GT is disabled, the hwconfig is unavailable and should be reported to userspace as having size 0. Reviewed-by: Tejas Upadhyay Link: https://lore.kernel.org/r/20251013200944.2499947-35-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe/uapi: loosen used tracking restriction

2025-09-24T10:43:29+00:00

Currently this is hidden behind perfmon_capable() since this is technically an info leak, given that this is a system wide metric. However the granularity reported here is always PAGE_SIZE aligned, which matches what the core kernel is already willing to expose to userspace if querying how many free RAM pages there are on the system, and that doesn't need any special privileges. In addition other drm drivers seem happy to expose this. The motivation here if with oneAPI where they want to use the system wide 'used' reporting here, so not the per-client fdinfo stats. This has also come up with some perf overlay applications wanting this information. Fixes: 1105ac15d2a1 ("drm/xe/uapi: restrict system wide accounting") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Joshua Santosh Cc: José Roberto de Souza Cc: Matthew Brost Cc: Rodrigo Vivi Cc: # v6.8+ Acked-by: Rodrigo Vivi Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20250919122052.420979-2-matthew.auld@intel.com

drm/xe: Never report L3 bank mask for media GT going forward

2025-09-09T17:04:29+00:00

We currently report an L3 bank mask as part of the GT topology on both GTs (primary and media) because a copy of the L3 bank fuse register exists on both GTs (e.g., $gsi_offset + 0x9130 on Xe3). After recent discussions it's come to light that the only known userspace software that uses this part of the uapi (the compute UMD and Mesa) only uses the value reported for the primary GT; the value reported for the media GT is ignored by both projects, and the media UMDs don't have any use for L3 information today. Since we always strive to have our uapi match the specific needs of userspace and not include additional unused baggage, let's officially drop L3 bank reporting on the media GT going forward and only keep it around for the primary GT where it actually gets used. This change will only apply to future platforms (Xe3 and later); even though it would probably be safe to remove it from Xe1/Xe2 as well, we don't want to take any chances with changing existing ABI. Note that we'd already disabled reading/reporting of the L3 bank for the media GT on PTL in commit 9ab440a9d042 ("drm/xe/ptl: L3bank mask is not available on the media GT") because it was discovered that the copy of the fuse registers on the media GT were just reporting a bogus ~0 value rather than an accurate mask. So this is just extending that PTL behavior forward to WCL and other future platforms. Note that we're also free to reinstate this part of the uapi in the future if/when some new userspace consumer emerges that _does_ have a use for media-specific L3 bank masks. Cc: Fei Yang Reviewed-by: Gustavo Sousa Link: https://lore.kernel.org/r/20250905215614.796247-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper