kernel/linux.git/drivers/gpu/drm/xe/xe_query.c, branch v6.19.11

drm/xe/query: Fix topology query pointer advance

2026-02-04T15:40:36+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 (cherry picked from commit c2a6859138e7f73ad904be17dd7d1da6cc7f06b3) Signed-off-by: Thomas Hellström

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

drm/xe: rename XE_WA to XE_GT_WA

2025-08-08T14:50:45+00:00

Now that there are two types of wa tables and infrastructure, be more concise in the naming of GT wa macros. v2: update the documentation Signed-off-by: Matt Atwood Reviewed-by: Rodrigo Vivi Link: https://lore.kernel.org/r/20250807214224.32728-1-matthew.s.atwood@intel.com Signed-off-by: Rodrigo Vivi

drm/xe: Remove unnecessary EU stall debug message

2025-07-18T22:05:32+00:00

The EU stall debug message may cause CI to complain on unsupported platforms. Remove it. Cc: Ashutosh Dixit Signed-off-by: Harish Chegondi Reviewed-by: Ashutosh Dixit Signed-off-by: Ashutosh Dixit Link: https://lore.kernel.org/r/dfb6a080b3442d481c567489aabe47e72f3e784c.1752870172.git.harish.chegondi@intel.com

drm/xe: Unify the initialization of VRAM regions

2025-07-16T19:15:00+00:00

Currently in the drivers we have defined VRAM regions per device and per tile. Initialization of these regions is done in two completely different ways. To simplify the logic of the code and make it easier to add new regions in the future, let's unify the way we initialize VRAM regions. v2: - fix doc comments in struct xe_vram_region - remove unnecessary includes (Jani) v3: - move code from xe_vram_init_regions_managers to xe_tile_init_noalloc (Matthew) - replace ioremap_wc to devm_ioremap_wc for mapping VRAM BAR (Matthew) - Replace the tile id parameter with vram region in the xe_pf_begin function. v4: - remove tile back pointer from struct xe_vram_region - add new back pointers: xe and migarte to xe_vram_region Signed-off-by: Piotr Piórkowski Cc: Stuart Summers Cc: Matthew Auld Cc: Jani Nikula Reviewed-by: Matthew Auld # rev3 Acked-by: Matthew Brost Link: https://lore.kernel.org/r/20250714184818.89201-6-piotr.piorkowski@intel.com Signed-off-by: Lucas De Marchi

drm/xe: Use dynamic allocation for tile and device VRAM region structures

2025-07-16T19:08:31+00:00

In future platforms, we will need to represent the device and tile VRAM regions in a more dynamic way, so let's abandon the static allocation of these structures and start use a dynamic allocation. v2: - Add a helpers for accessing fields of the xe_vram_region structure v3: - Add missing EXPORT_SYMBOL_IF_KUNIT for xe_vram_region_actual_physical_size Signed-off-by: Piotr Piórkowski Cc: Stuart Summers Cc: Matthew Auld Cc: Satyanarayana K V P Reviewed-by: Satyanarayana K V P Acked-by: Matthew Brost Link: https://lore.kernel.org/r/20250714184818.89201-3-piotr.piorkowski@intel.com Signed-off-by: Lucas De Marchi

drm/xe/xe_query: Use separate iterator while filling GT list

2025-07-02T23:08:54+00:00

The 'id' value updated by for_each_gt() is the uapi GT ID of the GTs being iterated over, and may skip over values if a GT is not present on the device. Use a separate iterator for GT list array assignments to ensure that the array will be filled properly on future platforms where index in the GT query list may not match the uapi ID. v2: - Include the missing increment of the iterator. (Jonathan) Cc: Jonathan Cavitt Reviewed-by: Jonathan Cavitt Link: https://lore.kernel.org/r/20250701201320.2514369-16-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe: Track maximum GTs per tile on a per-platform basis

2025-07-02T23:08:54+00:00

Today all of our platforms fall into one of three cases: * Single tile platforms with a single (primary) GT * Single tile platforms with two GTs (primary + media) * Two-tile platforms with a single GT (primary) in each Our numbering of GTs has been a bit inconsistent between platforms (e.g., GT1 is the media GT on some platforms, but the second tile's primary GT on others). In the future we'll likely have platforms that are both multi-tile and multi-GT, which will make the situation more confusing. We could also wind up with more than just two types of GTs at some point in the future. Going forward we should standardize the way we assign uapi GT IDs to internal GT structures. Let's declare that for userspace GT ID n, GT[n]'s tile = n / (max gt per tile) GT[n]'s slot within tile = n % (max gt per tile) We don't want the GT numbering to change for any of our current platforms since the current IDs are part of our ABI contract with userspace so this means we should track the 'max gt per tile' value on a per-platform basis rather than just using a single value across the driver. Encode this into device descriptors in xe_pci.c and use the per-platform number for various checks in the code. Constant XE_MAX_GT_PER_TILE will remain just as the maximum across all platforms for easy of sizing array allocations. Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20250701201320.2514369-12-matthew.d.roper@intel.com Signed-off-by: Matt Roper