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
Under CONFIG_DRM_XE_DEBUG_SRIOV print all policy KLVs sent to the
GuC for better diagnostics. This is similar what we are already
doing with VF configuration KLVs.
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-5-michal.wajdeczko@intel.com
We should force change of VFs scheduling priorities only after
initial change of the SCHED_IF_IDLE policy. Doing that also during
any later policy reprovisioning will overwrite changes done on the
individual per-VF scheduling priorities (currently only for PF).
While around also move priority change code to the _config component
to maintain a proper isolation. Also document our expectation about
the GuC version where the new meaning of the policy KLV is present.
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-4-michal.wajdeczko@intel.com
The pf_get_sched_priority() function returns scheduling priority
that we defined as u32 so while it works we shouldn't return int.
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-3-michal.wajdeczko@intel.com
Starting from the GuC firmware version 70.12.0 the meaning of the
POLICY_SCHED_IF_IDLE has changed, which now acts as a bulk update
of the VF_CFG_SCHED_PRIORITY configurations of all 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-2-michal.wajdeczko@intel.com
We only have support for G2H NO_RESPONSE_BUSY messages over MMIO,
but it turned out that GuC also uses that type of messages in CTB.
The following error was recently observed on BMG after adding VGT
policy updates to the GT restart sequence:
[] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: G2H channel broken on read, type=3, reset required
[] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: CT dequeue failed: -95
...
[] xe 0000:03:00.0: [drm] *ERROR* Tile0: GT1: Timed out wait for G2H, fence 21965, action 5502, done no
[] xe 0000:03:00.0: [drm] PF: Tile0: GT1: Failed to push 1 policy KLV (-ETIME)
[] xe 0000:03:00.0: [drm] Tile0: GT1: { key 0x8004 : no value } # engine_group_config
where type=3 was this unrecognized NO_RESPONSE_BUSY message.
Note that GuC might send the real RESPONSE message right after
the BUSY message, so we must be prepared to update our g2h_fence
data twice before sender actually wakes up and clears the flags.
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>
Link: https://patch.msgid.link/20260410110457.573-1-michal.wajdeczko@intel.com
Instead of using the proxy intel_step.h in display, just include the
common step file directly where needed. This allows us to remove the
compat intel_step.h header.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/83b5f13b7f863b9cbc61499bcff22af5cd822a0b.1774875688.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Use the shared stepping enums from include/drm/intel/step.h.
For now, define xe_step as intel_step to avoid mass renames at the same
time. For compat, we can remove the reverse macro.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patch.msgid.link/8173d9d753b343ba127d86277344248a6b1d0c3f.1774875688.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
- Fix missing leading space before closing */ in
comment block
- Add DRM_IOCTL_XE_EXEC_QUEUE_SET_PROPERTY to the
IOCTL overview list
- Add missing query types to the device query doc list:
DRM_XE_DEVICE_QUERY_UC_FW_VERSION,
DRM_XE_DEVICE_QUERY_OA_UNITS,
DRM_XE_DEVICE_QUERY_EU_STALL
- Fix ioctl's -> ioctls (not possessive, 2 occurrences)
- Remove duplicate parameter docs from
drm_xe_mem_range_attr overview (already documented
as inline member comments)
- Fix extra whitespace before /** on 2 lines in
drm_xe_mem_range_attr
- Add missing blank line before DRM_XE_VM_BIND_FLAG_DECOMPRESS
bullet to fix RST block quote warning
v3: more fix (item 4 to 7).
Assisted-by: GitHub Copilot:claude-opus-4.6
Cc: Xin Wang <x.wang@intel.com>
Reviewed-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260407030046.3394004-7-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Fix incorrect field names and formatting in code examples:
- .num_bb_per_exec -> .width (renamed struct field
in exec_queue_create examples)
- .num_eng_per_bb -> .num_placements (renamed struct
field in exec_queue_create examples)
- .atomic_val -> .atomic.val (correct nested struct
field access in madvise example)
- Remove unnecessary backslash escaping in UUID format
string (%\08x -> %08x)
- Fix descriptive text trapped inside code-block in
exec_queue_create doc (split into two code blocks)
v3: one more fix of split code-block in exec_queue_create doc.
Assisted-by: GitHub Copilot:claude-opus-4.6
Cc: Xin Wang <x.wang@intel.com>
Reviewed-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260407030046.3394004-6-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Fix incorrect kernel-doc cross-reference markup syntax
throughout xe_drm.h:
- @struct_name -> &struct name for cross-references to other
structs (19 occurrences)
- struct @name -> &struct name where struct keyword was
mixed with @ syntax (8 occurrences)
- enum @name -> &enum name for cross-references to other
enums (5 occurrences)
- &CONSTANT / @CONSTANT -> %CONSTANT for defines and enum
values (15 occurrences)
- @field references to members of other structs -> plain text,
since @ only applies to the current struct's members
(9 occurrences)
Per kernel-doc conventions (Documentation/doc-guide/kernel-doc.rst):
- '&struct name' creates hyperlinks to struct definitions
- '&enum name' creates hyperlinks to enum definitions
- '%NAME' references constants and defines
- '@name' is only for parameters/members of the current context
Assisted-by: GitHub Copilot:claude-opus-4.6
Suggested-by: Xin Wang <x.wang@intel.com>
Reviewed-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260407030046.3394004-5-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Fix various grammar issues in doc comments:
- flag are only valid -> flag is only valid
- should only ever used -> should only ever be used
- if isn't already -> if it isn't already
- Type of the this -> Type of this
- When sync passed in -> When sync is passed in
- the users responsibility -> the user's responsibility
- must qword aligned -> must be qword aligned
- for a observation -> for an observation
- a memory ranges -> memory ranges
- for each memory ranges -> for each memory range.
- Second ioctl call -> second ioctl call
Assisted-by: GitHub Copilot:claude-opus-4.6
Reviewed-by: Xin Wang <x.wang@intel.com>
Link: https://patch.msgid.link/20260407030046.3394004-3-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Initialize err = 0 in xe_tlb_inval_range_tilemask_submit to prevent a
possible uninitialized value return in the case where the tile_mask
somehow doesn't match any available tile ids.
This targets a static analysis issue.
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patch.msgid.link/20260316162003.64643-2-jonathan.cavitt@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Renaming:
The helper function res_to_mem_region is now xe_map_resource_to_region.
Abstraction:
The patch removes instances where block->private was accessed directly
to obtain VRAM region data allowing VRAM manager to own block->private
for future use cases.
V2(MattB): Add more detail about patch also adjust variable placement
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260407055107.2782450-2-tejas.upadhyay@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
This gets the memory sizes from the nodes and stores the limit
as 50% of those. I think eventually we should drop the limits
once we have memcg aware shrinking, but this should be more NUMA
friendly, and I think seems like what people would prefer to
happen on NUMA aware systems.
Cc: Christian Koenig <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This enable NUMA awareness for the shrinker on the
ttm pools.
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Dave Chinner <david@fromorbit.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The list_lru will now handle numa for us, so no need to keep
separate pool types for it. Just consolidate into the global ones.
This adds a debugfs change to avoid dumping non-existant orders due
to this change.
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is an initial port of the TTM pools for
write combined and uncached pages to use the list_lru.
This makes the pool's more NUMA aware and avoids
needing separate NUMA pools (later commit enables this).
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Dave Chinner <david@fromorbit.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This uses the newly introduced per-node gpu tracking stats,
to track GPU memory allocated via TTM and reclaimable memory in
the TTM page pools.
These stats will be useful later for system information and
later when mem cgroups are integrated.
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
While discussing memcg intergration with gpu memory allocations,
it was pointed out that there was no numa/system counters for
GPU memory allocations.
With more integrated memory GPU server systems turning up, and
more requirements for memory tracking it seems we should start
closing the gap.
Add two counters to track GPU per-node system memory allocations.
The first is currently allocated to GPU objects, and the second
is for memory that is stored in GPU page pools that can be reclaimed,
by the shrinker.
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Zi Yan <ziy@nvidia.com>
Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmnS4Y8eHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGe6AIAI4rjLLPlxUKQbx4
JP9lsKH7vqeIVvuMqzFau7+B8ngJ+80OESnBF7n43oNEqdJ0NYiL+rPtcGgBjZDP
yUu5DlzVSxpAIQBZe2Nc0dz/5NbT9QxKyC5Yl/whpNIR7UHx1RFvDJYxwN9xKxTw
ggLQevKAnHrKjIOKjq70Yqz2T1JMXc9Wp/xpur0oGioiFW/lH24CgHDXjE2Ka9oD
wqhotzThuSaaVDmqZ8WNFKxx2onR4r8/NpljaVT2mWRJ2+IMF4pMOBJZRQiNZtRa
1CsoJ3aV6pslAsuC1dLboCMul48VUgyu7l3xQwXVuA5bRO1jqt5ILWC10g09OItU
7CxGTno=
=1TRg
-----END PGP SIGNATURE-----
Merge v7.0-rc7 into drm-next
Thomas Zimmermann needs 2f42c1a616 ("drm/ast: dp501: Fix
initialization of SCU2C") for drm-misc-next.
Conflicts:
- drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c
Just between e927b36ae1 ("drm/amd/display: Fix NULL pointer
dereference in dcn401_init_hw()") and it's cherry-pick that confused
git.
- drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
Deleted in 6b0a611628 ("drm/amd/pm: Unify version check in SMUv11")
but some cherry-picks confused git. Same for v12/v14.
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
Six headers use __XE_<NAME>_H__ (double-underscore prefix and suffix)
as their include guards. Normalize them to the single-underscore
_XE_<NAME>_H_ convention used by the rest of the xe codebase.
Files fixed:
- xe_eu_stall.h: __XE_EU_STALL_H__ -> _XE_EU_STALL_H_
- xe_nvm.h: __XE_NVM_H__ -> _XE_NVM_H_
- xe_pxp.h: __XE_PXP_H__ -> _XE_PXP_H_
- xe_pxp_debugfs.h: __XE_PXP_DEBUGFS_H__ -> _XE_PXP_DEBUGFS_H_
- xe_pxp_submit.h: __XE_PXP_SUBMIT_H__ -> _XE_PXP_SUBMIT_H_
- xe_pxp_types.h: __XE_PXP_TYPES_H__ -> _XE_PXP_TYPES_H_
No functional change.
Suggested-by: Nitin Gote <nitin.r.gote@intel.com>
Assisted-by: GitHub Copilot:claude-opus-4.6
Reviewed-by: Nitin Gote <nitin.r.gote@intel.com>
Link: https://patch.msgid.link/20260317215732.2208976-12-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Two headers use XE_<NAME>_H_ (no leading underscore) as their include
guard. Normalize them to _XE_<NAME>_H_ to match the convention used
across the xe codebase.
Files fixed:
- xe_drm_ras.h: XE_DRM_RAS_H_ -> _XE_DRM_RAS_H_
- xe_hw_error.h: XE_HW_ERROR_H_ -> _XE_HW_ERROR_H_
No functional change.
Suggested-by: Nitin Gote <nitin.r.gote@intel.com>
Assisted-by: GitHub Copilot:claude-opus-4.6
Reviewed-by: Nitin Gote <nitin.r.gote@intel.com>
Link: https://patch.msgid.link/20260317215732.2208976-11-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Four headers use _XE_<NAME>_H (no trailing underscore) as their include
guard. Normalize them to _XE_<NAME>_H_ to match the dominant convention
used across the xe codebase.
Files fixed:
- xe_guc_capture.h: _XE_GUC_CAPTURE_H -> _XE_GUC_CAPTURE_H_
- xe_guc_capture_types.h: _XE_GUC_CAPTURE_TYPES_H -> _XE_GUC_CAPTURE_TYPES_H_
- xe_guc_fwif.h: _XE_GUC_FWIF_H -> _XE_GUC_FWIF_H_
- xe_uc_fw_abi.h: _XE_UC_FW_ABI_H -> _XE_UC_FW_ABI_H_
No functional change.
Suggested-by: Nitin Gote <nitin.r.gote@intel.com>
Assisted-by: GitHub Copilot:claude-opus-4.6
Reviewed-by: Nitin Gote <nitin.r.gote@intel.com>
Link: https://patch.msgid.link/20260317215732.2208976-10-shuicheng.lin@intel.com
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
