The write to RING_HWSTAM to disable hardware status page writes on
interrupt was unnecessarily open-coded in xe_hw_engine_enable_ring();
it's preferable to do such programming in the engine_entries[] RTP table
since gets reflected/verified in debugfs, and will also automatically
ensure that the register is properly saved/restored around engine
resets.
In this case the HWSTAM register wasn't explicitly added to the GuC ADS'
save-restore list, so there was the potential for the value to be lost
on engine resets. This doesn't seem to have happened in practice, so
likely the GuC firmware is automatically saving/restoring this register
on our behalf, but we shouldn't rely on this implicit behavior going
forward.
One other slight change with this patch is that HWSTAM will now be
programmed on the vestigial execlist (non-GuC) initialization path.
Since the register's default value is 0x0 and the documentation
indicates that it's only legal to leave a single bit unmasked at a time,
this likely would have been an illegal situation if the execlist code
were actually usable.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-4-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Xe1 platforms used the BLIT_CCTL register to specify the MOCS value that
would be used for BCS engine instructions that did not have a way of
specifying a MOCS index directly. From Xe2 onward, all BCS instructions
now have explicit instruction fields for specifying a MOCS index and the
BLIT_CCTL register is now a dummy register with no valid fields.
Although continuing to write to it today has no effect, the register
could repurposed in future platforms, so restrict the BLIT_CCTL RTP
entry to only apply to Xe1 platforms.
Bspec: 60280
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-3-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
All RTP table entries are required to have at least one rule. In cases
where an entry should apply unconditionally across all platforms we've
been using a graphics version range of 12.00 - forever since this covers
all platforms supported by the driver. However if the primary GT is
disabled via configfs (not actually possible today, but probably
possible in the future) or if we have a future platform that lacks a
primary GT and only supports media/display, this rule would cause
important programming to fail to apply on the media GT.
Add a simple match function that just always returns true
unconditionally. This solves the worries above while also being more
immediately human-readable.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-2-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Most register programming for engine setup happens via RTP tables in
hw_engine_setup_default_state(). Move the programming of RCU_MODE[0]
which enables the platform's CCS engine(s) there. This both makes the
code more consistent (other RCU_MODE register programming is already
happening in this RTP table) and improves debuggability (since RTP
contents and checks of their correct programming are exposed via
debugfs). It also helps consolidate the regular driver initialization
paths with the vestigial and currently unused execlist (i.e., non-GuC)
initialization.
With the original programming, the RCU_MODE register (which is a single
global register, not a per-engine register) was getting re-programmed
with the same value during the initialization of each CCS engine. When
moved to the RTP table, we use the xe_rtp_match_first_render_or_compute
match function so that it will just be programmed once, while doing the
initialization for the first RCS/CCS engine, which avoids the redundant
and unnecessary repetition.
We can also safely drop the explicit addition of RCU_MODE from the GuC
ADS save-restore list now since all registers programmed via RTP tables
are automatically added to the GuC's list.
v2:
- Only enable CCS engines on Xe_HP and later. Even though Xe_LP
platforms technically have a CCS engine, it's never been enabled on
i915 or Xe due to other issues on these old platforms.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260424-engine-setup-v2-1-59cc620a25f1@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Although the bspec currently indicates that steered reads/writes to L3
register ranges are never terminated for physically present instances
(regardless of fusing) on Xe2, it turns out this is information is
incorrect. The hardware architects have also confirmed that the current
documentation is wrong (or that possibly the wording was intended to be
interpreted in a different way), but have not yet provided an official
spec update.
All of our driver's writes to registers in these ranges are done as
multicast, so steering is not actually important to proper driver
operation; the only impact of this documentation mistake is that on some
fused-down SKUs where the first L3 bank is absent we're not able to
properly read back the values that were written to those registers to
confirm that the writes were applied correctly (e.g., when using the
register-save-restore-check debugfs interface).
Since we don't have an official spec update yet, let's assume that
Xe2/Xe3 use the same fuse => steering logic as Xe3p. I.e., remove
L3BANK and NODE register ranges from the "INSTANCE0" steering group and
add handle them with dedicated handling according to the L3 fuses. From
testing on various fused-down platforms this does appear to give proper
steering and fix the failures reported by IGT's
igt@xe_debugfs@check-gt-reg-sr test.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7706
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Link: https://patch.msgid.link/20260421-xe2_l3bank_steering-v1-1-613158a27383@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Add validation in xe_vm_bind_ioctl() to reject PAT indices
with XE_COH_NONE coherency mode when used with
DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR.
CPU address mirror mappings use system memory that is CPU
cached, which makes them incompatible with COH_NONE PAT
indices. Allowing COH_NONE with CPU cached buffers is a
security risk, as the GPU may bypass CPU caches and read
stale sensitive data from DRAM.
Although CPU_ADDR_MIRROR does not create an immediate
mapping, the backing system memory is still CPU cached.
Apply the same PAT coherency restrictions as
DRM_XE_VM_BIND_OP_MAP_USERPTR.
v2:
- Correct fix tag
v6:
- No change
v7:
- Correct fix tag
v8:
- Rebase
v9:
- Limit the restrictions to iGPU
v10:
- Just add the iGPU logic but keep dGPU logic
Fixes: b43e864af0 ("drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR")
Cc: <stable@vger.kernel.org> # v6.15+
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Cc: Mathew Alwin <alwin.mathew@intel.com>
Cc: Michal Mrozek <michal.mrozek@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Jia Yao <jia.yao@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Michal Mrozek <michal.mrozek@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260417055917.2027459-3-jia.yao@intel.com
Add validation in xe_vm_madvise_ioctl() to reject PAT indices with
XE_COH_NONE coherency mode when applied to CPU cached memory.
Using coh_none with CPU cached buffers is a security issue. When the
kernel clears pages before reallocation, the clear operation stays in
CPU cache (dirty). GPU with coh_none can bypass CPU caches and read
stale sensitive data directly from DRAM, potentially leaking data from
previously freed pages of other processes.
This aligns with the existing validation in vm_bind path
(xe_vm_bind_ioctl_validate_bo).
v2(Matthew brost)
- Add fixes
- Move one debug print to better place
v3(Matthew Auld)
- Should be drm/xe/uapi
- More Cc
v4(Shuicheng Lin)
- Fix kmem leak issues by the way
v5
- Remove kmem leak because it has been merged by another patch
v6
- Remove the fix which is not related to current fix
v7
- No change
v8
- Rebase
v9
- Limit the restrictions to iGPU
v10
- No change
Fixes: ada7486c56 ("drm/xe: Implement madvise ioctl for xe")
Cc: <stable@vger.kernel.org> # v6.18+
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Cc: Mathew Alwin <alwin.mathew@intel.com>
Cc: Michal Mrozek <michal.mrozek@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Jia Yao <jia.yao@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Michal Mrozek <michal.mrozek@intel.com>
Acked-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260417055917.2027459-2-jia.yao@intel.com
Introduce a new 'clear-error-counter' drm_ras command to reset the counter
value for a specific error counter of a given node.
The command is a 'do' netlink request with 'node-id' and 'error-id'
as parameters with no response payload.
Usage:
$ sudo ynl --family drm_ras --do clear-error-counter --json \
'{"node-id":1, "error-id":1}'
None
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Zack McKevitt <zachary.mckevitt@oss.qualcomm.com>
Cc: Lijo Lazar <lijo.lazar@amd.com>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Riana Tauro <riana.tauro@intel.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Raag Jadav <raag.jadav@intel.com>
Link: https://patch.msgid.link/20260409073318.2909379-5-riana.tauro@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Maxime Ripard <mripard@redhat.com>
In xe_devcoredump_snapshot_free(), ss->gt may be NULL when the snapshot
was never fully populated (e.g., when cleanup is triggered without a
prior capture). Guard the xe_guc_capture_put_matched_nodes() call with
IS_ERR_OR_NULL() to prevent a null dereference.
In xe_devcoredump_free(), the deferred work is only queued when a
coredump is captured, so guard cancel_work_sync() with a check on
coredump->captured.
Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com>
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Link: https://patch.msgid.link/20260326181017.2060209-1-zhanjun.dong@intel.com
Wrap pat.idx[] reads with xe_cache_pat_idx() so invalid PAT index use
is caught by xe_assert() in debug builds.
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260416045526.536497-4-x.wang@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Initialize XE_CACHE_NONE_COMPRESSION PAT index to XE_PAT_INVALID_IDX by
default, same as XE_CACHE_WB_COMPRESSION. Platforms that support this
cache mode will override it in xe_pat_init_early(). This ensures that
accidental use on unsupported platforms can be detected.
A subsequent patch introduces a helper to assert on invalid PAT index
access at all call sites.
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260416045526.536497-3-x.wang@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Ensure all pat_index definitions consistently use u16 type across
the XE driver. This addresses two remaining instances where pat_index
was incorrectly typed:
- xe_vm_snapshot structure used int for pat_index field
- xe_device pat.idx array used u32 instead of u16
This cleanup improves type consistency and ensures proper alignment
with the PAT subsystem design.
Signed-off-by: Xin Wang <x.wang@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260416045526.536497-2-x.wang@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Command parser relative MMIO addressing needs to be enabled when writing
to the register.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Fixes: ca33cd271e ("drm/xe/xelp: Add Wa_18022495364")
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260420131603.70357-1-tvrtko.ursulin@igalia.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
When xe_gsc_read_out_header() fails, query_compatibility_version()
returns directly instead of jumping to the out_bo label. This skips
the xe_bo_unpin_map_no_vm() call, leaving the BO pinned and mapped
with no remaining reference to free it.
Fix by using goto out_bo so the error path properly cleans up the BO,
consistent with the other error handling in the same function.
Fixes: 0881cbe040 ("drm/xe/gsc: Query GSC compatibility version")
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20260417163308.3416147-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Enable HWMON energy attributes for CRI, which are available through MMIO
registers.
Although these attributes can also be accessed via PMT, MMIO is preferred
as it avoids dependency on ocode firmware load in late binding scenario.
v2: Rephrase commit message. (Anshuman)
Signed-off-by: Karthik Poosa <karthik.poosa@intel.com>
Reviewed-by: Soham Purkait <soham.purkait@intel.com>
Link: https://patch.msgid.link/20260417041456.818668-1-karthik.poosa@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Update xe_hwmon_pcode_read_power_limit() and
xe_hwmon_pcode_rmw_power_limit() to read the accepted power limit for
discrete platforms post CRI.
For platforms before CRI only the last written pcode value was available.
From CRI onwards, pcode exposes a new param2 value 2 that allows reading
the accepted power limit by the hardware.
v2:
- Read resolved power limit in xe_hwmon_pcode_rmw_power_limit()
as well. (Badal)
- Rephrase commit message. (Badal)
- Add prepare_power_limit_param2() to prepare param2 for mailbox power
limit read.
Signed-off-by: Karthik Poosa <karthik.poosa@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://patch.msgid.link/20260323115836.3737300-1-karthik.poosa@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The skip_mtcfg descriptor flag is unused and expected to remain that
way. Drop it.
Single-tile platforms are already identified by a zero/unset value for
max_remote_tiles and don't need/use this flag to avoid trying to read
out multi-tile configuration. PVC is currently the only multi-tile
platform, and PVC uses MTCFG so this flag is not set. The current
expectation is that if/when future multi-tile platforms show up, they
will also use the MTCFG register in the same manner as PVC, meaning that
they won't have any need to set 'skip_mtcfg' either.
Even if a future platform does change how multi-tile configuration gets
probed (e.g., using some different register), simply doing an early return
from xe_info_probe_tile_count() would probably not be the correct logic
to handle that anyway.
Bspec: 53146
Reviewed-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260416-no-skip-mtcfg-v1-1-c8ea26d81530@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
When preparing number of impacted VFs parameter for the reporting
helper function, we wrongly ended with adding +1 (representing PF)
twice, since local variable total_vfs was already adjusted. This
resulted in printing a message that was referring to an invalid VF:
[] xe ... [drm] PF: Enabled 2 of 24 VFs
[] xe ... [drm] PF: Tile0: GT0: PF..VF25 provisioned with 0(low) scheduling priority
Fix variable initialization and adjust the loop accordingly.
Fixes: fbbf73a81b ("drm/xe/pf: Force new VFs prorities only once")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260416131831.7302-1-michal.wajdeczko@intel.com
In xe_eu_stall_stream_close(), drm_dev_put() is called before the
stream is disabled and its resources are freed. If this drops the
last reference, the device structures could be freed while the
subsequent cleanup code still accesses them, leading to a
use-after-free.
Fix this by moving drm_dev_put() after all device accesses are
complete. This matches the ordering in xe_oa_release().
Fixes: 9a0b11d4cf ("drm/xe/eustall: Add support to init, enable and disable EU stall sampling")
Cc: Harish Chegondi <harish.chegondi@intel.com>
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Reviewed-by: Harish Chegondi <harish.chegondi@intel.com>
Link: https://patch.msgid.link/20260415225428.3399934-1-shuicheng.lin@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Fix kernel-doc references that point to wrong type or parameter names:
- xe_guc_capture_types.h: register_data_type ->
capture_register_data_type to match actual enum name
- xe_oa_types.h: enum @drm_xe_oa_format_type ->
enum drm_xe_oa_format_type (spurious '@' before type name)
- xe_pt_walk.h: @sizes -> @shifts to match actual struct member,
@start -> @addr to match actual parameter name,
page.table. -> page table. (typo)
Assisted-by: GitHub Copilot:claude-sonnet-4.6
Reviewed-by: Brian Nguyen <brian3.nguyen@intel.com>
Link: https://patch.msgid.link/20260414225457.3687449-5-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Fix doc comment formatting that does not conform to kernel-doc syntax
rules:
- xe_guc_relay_types.h: Add missing space after '/**' in member doc
comment (/**@lock -> /** @lock)
- xe_oa_types.h: Fix struct documentation to use proper kernel-doc
format (/** @xe_oa_buffer: -> /** struct xe_oa_buffer -)
- xe_pagefault_types.h: Use dash instead of colon as separator in
struct doc (struct xe_pagefault_queue: -> struct xe_pagefault_queue -)
- xe_pt_walk.h: Use dash instead of colon as separator in function
docs (xe_pt_num_entries: -> xe_pt_num_entries -,
xe_pt_offset: -> xe_pt_offset -)
Assisted-by: GitHub Copilot:claude-sonnet-4.6
Reviewed-by: Brian Nguyen <brian3.nguyen@intel.com>
Link: https://patch.msgid.link/20260414225457.3687449-4-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Add the required '@' prefix to member documentation tags that were
missing it. Without the prefix, kernel-doc does not associate the
comment with the struct member.
- xe_guc_ct_types.h: snapshot_ct -> @snapshot_ct,
snapshot_log -> @snapshot_log
- xe_pagefault_types.h: consumer.reserved -> @consumer.reserved
- xe_pt_types.h: addr -> @addr
Assisted-by: GitHub Copilot:claude-sonnet-4.6
Reviewed-by: Brian Nguyen <brian3.nguyen@intel.com>
Link: https://patch.msgid.link/20260414225457.3687449-3-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
When an app exits abruptly (for example due to the user hitting ctrl+c),
any of its queues that are still active on the HW are immediately
killed. As part of this process, the driver tells the GuC to preempt
the queues off the HW and to reset them if they don't preempt.
This can cause a reset log to be printed to dmesg, which can be confusing
to users as resets are commonly tied to errors, while any resets performed
in this case are just done to speed up the cleanup. Also, those reset
messages are not useful for debug, because we don't care what happens to
a queue once its app has exited.
The only case where a queue might be killed before the app that owns it
has exited is if the queue uses PXP and a PXP termination occurs. In
such scenario a log might be useful, but rather than a reset log it is
better to have a communication that the queue is being killed.
Therefore, we can silence the reset log for all killed queues and add a
simple debug log to record when a PXP queue is killed to cover that case.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260413230724.714884-2-daniele.ceraolospurio@intel.com
Apply engine tuning for TileY 2x2 walk pattern, starting with IP
Xe3p_LPG.
v2: move to xe tunings (MattR)
Bspec: 72161, 73720
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Link: https://patch.msgid.link/20260413200825.4054940-1-clinton.a.taylor@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Two error handling issues exist in xe_exec_queue_create_ioctl():
1. When xe_hw_engine_group_add_exec_queue() fails, the error path jumps
to put_exec_queue which skips xe_exec_queue_kill(). If the VM is in
preempt fence mode, xe_vm_add_compute_exec_queue() has already added
the queue to the VM's compute exec queue list. Skipping the kill
leaves the queue on that list, leading to a dangling pointer after
the queue is freed.
2. When xa_alloc() fails after xe_hw_engine_group_add_exec_queue() has
succeeded, the error path does not call
xe_hw_engine_group_del_exec_queue() to remove the queue from the hw
engine group list. The queue is then freed while still linked into
the hw engine group, causing a use-after-free.
Fix both by:
- Changing the xe_hw_engine_group_add_exec_queue() failure path to jump
to kill_exec_queue so that xe_exec_queue_kill() properly removes the
queue from the VM's compute list.
- Adding a del_hw_engine_group label before kill_exec_queue for the
xa_alloc() failure path, which removes the queue from the hw engine
group before proceeding with the rest of the cleanup.
Fixes: 7970cb3696 ("'drm/xe/hw_engine_group: Register hw engine group's exec queues")
Cc: Francois Dugast <francois.dugast@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Assisted-by: Claude:claude-opus-4.6
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260408020647.3397933-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
When xe_dma_buf_init_obj() fails, the attachment from
dma_buf_dynamic_attach() is not detached. Add dma_buf_detach() before
returning the error. Note: we cannot use goto out_err here because
xe_dma_buf_init_obj() already frees bo on failure, and out_err would
double-free it.
Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4.6
Reviewed-by: Mattheq Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260408175255.3402838-5-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
When drm_gpuvm_resv_object_alloc() fails, the pre-allocated storage bo
is not freed. Add xe_bo_free(storage) before returning the error.
xe_dma_buf_init_obj() calls xe_bo_init_locked(), which frees the bo on
error. Therefore, xe_dma_buf_init_obj() must also free the bo on its own
error paths. Otherwise, since xe_gem_prime_import() cannot distinguish
whether the failure originated from xe_dma_buf_init_obj() or from
xe_bo_init_locked(), it cannot safely decide whether the bo should be
freed.
Add comments documenting the ownership semantics: on success, ownership
of storage is transferred to the returned drm_gem_object; on failure,
storage is freed before returning.
v2: Add comments to explain the free logic.
Fixes: eb289a5f6c ("drm/xe: Convert xe_dma_buf.c for exhaustive eviction")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4.6
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260408175255.3402838-4-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
When XE_BO_FLAG_GGTT_ALL is set without XE_BO_FLAG_GGTT, the function
returns an error without freeing a caller-provided bo, violating the
documented contract that bo is freed on failure.
Add xe_bo_free(bo) before returning the error.
Fixes: 5a3b0df25d ("drm/xe: Allow bo mapping on multiple ggtts")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4.6
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260408175255.3402838-3-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
When type is ttm_bo_type_device and aligned_size != size, the function
returns an error without freeing a caller-provided bo, violating the
documented contract that bo is freed on failure.
Add xe_bo_free(bo) before returning the error.
Fixes: 4e03b58414 ("drm/xe/uapi: Reject bo creation of unaligned size")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4.6
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260408175255.3402838-2-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
xe_exec_queue_tlb_inval_last_fence_put_unlocked() uses q->vm->xe as the
first argument to xe_assert(). This function is called unconditionally
from xe_exec_queue_destroy() for all queues, including kernel queues
that have q->vm == NULL (e.g., queues created during GT init in
xe_gt_record_default_lrcs() with vm=NULL).
While current compilers optimize away the q->vm->xe dereference (even
in CONFIG_DRM_XE_DEBUG=y builds, the compiler pushes the dereference
into the WARN branch that is only taken when the assert condition is
false), the code is semantically incorrect and constitutes undefined
behavior in the C abstract machine for the NULL pointer case.
Use gt_to_xe(q->gt) instead, which is always valid for any exec queue.
This is consistent with how xe_exec_queue_destroy() itself obtains the
xe_device pointer in its own xe_assert at the top of the function.
Fixes: b2d7ec41f2 ("drm/xe: Attach last fence to TLB invalidation job queues")
Assisted-by: Claude:claude-opus-4.6
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260409003449.3405767-1-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Stop tracking admin-only PF mode in a separate `xe->sriov.pf.admin_only`
field and use `xe_device_is_admin_only(xe)` as the single source of
admin mode.
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@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>
Link: https://patch.msgid.link/20260413095637.2871287-2-satyanarayana.k.v.p@intel.com
When a PF is configured in admin-only mode, it is intended for management
only and must not expose workload-facing capabilities to userspace.
Limit the exposed ioctl set in admin-only PF mode to XE_DEVICE_QUERY and
XE_OBSERVATION, and suppress capability-bearing query payloads so that
the userspace cannot discover execution-related device details in this
mode.
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Dunajski Bartosz <bartosz.dunajski@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patch.msgid.link/20260409154423.2499340-5-satyanarayana.k.v.p@intel.com
The suballocator algorithm tracks a hole cursor at the last allocation
and tries to allocate after it. This is optimized for fence-ordered
progress, where older allocations are expected to become reusable first.
In fence-enabled mode, that ordering assumption holds. In fence-disabled
mode, allocations may be freed in arbitrary order, so limiting allocation
to the current hole window can miss valid free space and fail allocations
despite sufficient total space.
Use DRM memory manager instead of sub-allocator to get rid of this issue
as CCS read/write operations do not use fences.
Fixes: 864690cf4d ("drm/xe/vf: Attach and detach CCS copy commands with BO")
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260408110145.1639937-6-satyanarayana.k.v.p@intel.com
Add a memory pool to allocate sub-ranges from a BO-backed pool
using drm_mm.
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260408110145.1639937-5-satyanarayana.k.v.p@intel.com
The register-save-restore debugfs prints whitelist entries as offset
ranges. E.g.,
REG[0x39319c-0x39319f]: allow read access
for a single dword-sized register. However the GENMASK value used to
set the lower bits to '1' for the upper bound of the whitelist range
incorrectly included one more bit than it should have, causing the
whitelist ranges to sometimes appear twice as large as they really were.
For example,
REG[0x6210-0x6217]: allow rw access
was also intended to be a single dword-sized register whitelist (with a
range 0x6210-0x6213) but was printed incorrectly as a qword-sized range
because one too many bits was flipped on. Similar 'off by one' logic
was applied when printing 4-dword register ranges and 64-dword register
ranges as well.
Correct the GENMASK logic to print these ranges in debugfs correctly.
No impact outside of correcting the misleading debugfs output.
Fixes: d855d2246e ("drm/xe: Print whitelist while applying")
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Link: https://patch.msgid.link/20260408-regsr_wl_range-v1-1-e9a28c8b4264@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
ROW_CHICKEN5 is a masked register (i.e., to adjust the value of any of
the lower 16 bits, the corresponding bit in the upper 16 bits must also
be set). Add the XE_REG_OPTION_MASKED to its definition; failure to do
so will cause workaround updates of this register to not apply properly.
Bspec: 56853
Fixes: 835cd6cbb0 ("drm/xe/xe3p_lpg: Add initial workarounds for graphics version 35.10")
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20260410-xe3p_tuning-v1-3-e206a62ee38f@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
From Xe2 onward (i.e., all platforms officially supported by the Xe
driver), the GAMSTLB_CTRL register is located at offset 0x477C and
represented by the macro "GAMSTLB_CTRL" in code. However the register
formerly resided at offset 0xCF4C on Xe1-era platforms, and we also have
macro XEHP_GAMSTLB_CTRL that represents this old offset in the
unofficial/developer-only Xe1 code. When tuning for the register was
added for Xe3p_LPG, the old Xe1-era macro was accidentally used instead
of the proper macro for Xe2 and beyond, causing the tuning to not be
applied properly. Use the proper definition so that the correct offset
is written to.
Bspec: 59298
Fixes: 377c89bfaa ("drm/xe/xe3p_lpg: Set STLB bank hash mode to 4KB")
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20260410-xe3p_tuning-v1-2-e206a62ee38f@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Whereas the tuning guide gave guidance on adjusting various CCCHKNREG1
on past platforms, starting from Xe3p the guidance is "Leave register at
HW default settings." Set a version range upper bound of "34.99" so
that the current programming will stop being applied on any Xe3p
platforms that have graphics version 35.
Bspec: 72161
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/20260410-xe3p_tuning-v1-1-e206a62ee38f@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Default VF scheduling configuration is the same as for the PF and
includes unlimited execution quantum (EQ) and unlimited preemption
timeout (PT). While this setup gives the most flexibility it does
not protect the PF or VFs from other VF that could constantly submit
workloads without any gaps that would let GuC do a VF-switch.
To avoid that, do some trivial auto-provisioning and configure PF
and all VFs with 16ms EQ and PT. This setup should allow GuC to
perform a full round-robin with up to 63 VFs within 2s, which in
turn should match expectations from most of the VMs using VFs.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> #v1
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patch.msgid.link/20260402191726.4932-14-michal.wajdeczko@intel.com
We already have functions to bulk provision execution quantum and
preemption timeout, but they are applying changes to all possible
VFs, while in upcoming patch we would like to provision only subset
of available VFs.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260402191726.4932-13-michal.wajdeczko@intel.com
In upcoming patches we will want to show which VFs were already
provisioned with resources other than LMEM(VRAM). Convert code
from the LMEM reporting function into a more generic helper that
can handle both u32 and u64 resources and can report also PF.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260402191726.4932-12-michal.wajdeczko@intel.com
Once we have disabled VFs there is no point in keeping potentially
limited PF scheduling provisioning as we want to complete a cleanup
of the VFs resources and return to the pure native mode, the same
as before VFs were enabled, as soon as possible.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260402191726.4932-11-michal.wajdeczko@intel.com
In upcoming patch we will need to update sched_if_idle policy when
we already hold the provisioning mutex. Split existing function
into two variants to allow that.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260402191726.4932-10-michal.wajdeczko@intel.com
In addition to the hard resources (like GGTT, CTXs, DBs) we should
also check if VF was already configured (by sysfs or debugfs) with
optional parameters like execution quantum (EQ), preemption timeout
(PT) or scheduling priority (PRIO) as otherwise we might miss to
send to the GuC updated latest values after a resume or GT reset.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260402191726.4932-9-michal.wajdeczko@intel.com
After a reset we missed to reprovision VFs scheduling priority config.
But as of today, the GuC firmware allows to change scheduling priority
using config SCHED_PRIORITY KLV only for the PF and configuration of
all VFs relies on the previously applied value of the SCHED_IF_IDLE
policy. Use this policy value to check and decide whether we need to
encode VF priority KLV while reprovisioning this VF.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260402191726.4932-8-michal.wajdeczko@intel.com
There is no need to send policy updates to the GuC if policies
were not changed from the default settings (usually zero value).
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260402191726.4932-7-michal.wajdeczko@intel.com
In addition to the reprovisioning of individual VFs configurations,
we should also reprovision GuC global policy settings. Note that we
already had a draft function for that but we missed to call it once
we started handling GT reset. Reuse it now but don't take extra RPM
as this is now a caller responsibility and drop unused parameter.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patch.msgid.link/20260402191726.4932-6-michal.wajdeczko@intel.com
