Shuicheng Lin [Mon, 27 Oct 2025 20:21:19 +0000 (20:21 +0000)]
drm/xe: Limit number of jobs per exec queue
Add a limit to the number of jobs that can be queued in a single
exec queue to avoid potential resource exhaustion.
A new field `job_cnt` is introduced in `struct xe_exec_queue` to
track the number of active DRM jobs, along with a maximum limit
`XE_MAX_JOB_COUNT_PER_EXEC_QUEUE` set to 1000.
If the job count exceeds this threshold, `xe_exec_ioctl()` now
returns `-EAGAIN` to signal that the caller should retry later.
A trace event is added to track when the limit is reached:
"xe_exec_queue_reach_max_job_count: dev=0000:03:00.0, job count
exceeded the maximum limit (1000) per exec queue. engine_class=0x3,
logical_mask=0x1, guc_id=2"
v3: add assert in xe_exec_queue_destroy that q->job_cnt is zero. (Matt)
v2 (Matt):
- add log to trace the limit is hit.
- Change max count from 0x1000 to 1000.
- Use atomic_t for job_cnt.
Suggested-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20251027202118.3339905-2-shuicheng.lin@intel.com
Michal Wajdeczko [Fri, 24 Oct 2025 20:58:25 +0000 (22:58 +0200)]
drm/xe/pf: Access VF's register using dedicated MMIO view
Instead of creating ad-hoc new register definitions with altered
register addresses to mimic the VF's access to these registers,
prepare new MMIO instance per required VF, with shifted internal
location of the register map. This will allow to use unmodified
register definitions in all calls to xe_mmio() functions.
Nitin Gote [Mon, 27 Oct 2025 09:26:43 +0000 (14:56 +0530)]
drm/xe/xe3: Add WA_14024681466 for Xe3_LPG
Apply WA_14024681466 to Xe3_LPG graphics IP versions from 30.00 to 30.05.
v2: (Matthew Roper)
- Remove stepping filter as workaround applies to all steppings.
- Add an engine class filter so it only applies to the RENDER engine.
Michal Wajdeczko [Sat, 25 Oct 2025 12:49:05 +0000 (14:49 +0200)]
drm/xe/pf: Fix VF FLR synchronization between all GTs
If subsequent VF FLR request is triggered when previous VF FLR
sequence is still being processed, we ignore it as not needed.
But in case of the multi-GT platforms, one GT may already finish
its VF FLR processing and will start a new sequence, which includes
new cross-GT synchronization point. However, since other GT may
be still busy with post-sync cleanup steps, this will put on hold
this new FLR sequence, which might never finish due to lack of any
future synchronization checkouts.
Add additional cross-GT FLR synchronization point when each GT
ends processing its own FLR sequence. This should also help to
cover the case when one GT fails FLR processing before reaching
the first synchronization point.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6287 Fixes: 2a8fcf7cc950 ("drm/xe/pf: Synchronize VF FLR between all GTs") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patch.msgid.link/20251025124906.5264-1-michal.wajdeczko@intel.com
Sanjay Yadav [Thu, 23 Oct 2025 12:14:54 +0000 (17:44 +0530)]
drm/xe: Fix spelling and typos across Xe driver files
Corrected various spelling mistakes and typos in multiple
files under the Xe directory. These fixes improve clarity
and maintain consistency in documentation.
v2
- Replaced all instances of "XE" with "Xe" where it referred
to the driver name
- of -> for
- Typical -> Typically
v3
- Revert "Xe" to "XE" for macro prefix reference
Matt Roper [Fri, 24 Oct 2025 20:08:35 +0000 (13:08 -0700)]
drm/xe/configfs: Drop MAX_GT_TYPE_CHARS constant
Early revisions of commit 7abd69278bb5 ("drm/xe/configfs: Add attribute
to disable GT types") used MAX_GT_TYPE_CHARS not only to size the
constant name field, but also for some of the string matching logic. By
the time the patch finally landed, the constant was no longer needed for
parsing. Stop using it for the string field definition as well; this
eliminates the risk that we forget to update the constant if we ever add
a GT type name longer than seven characters.
Matt Roper [Tue, 21 Oct 2025 22:45:56 +0000 (15:45 -0700)]
drm/xe/xe3p_xpc: Add MCR steering for NODE and L3BANK ranges
The bspec was originally missing the information related to steering of
L3-related ranges. Now that a late-breaking spec update has added the
necessary information, implement the steering rules in the code. Note
that the sole L3BANK range is the same as the one used on Xe_LPG, so we
can re-use the existing table for that MCR type.
Matt Roper [Tue, 21 Oct 2025 22:45:55 +0000 (15:45 -0700)]
drm/xe/xe3p_xpc: Treat all PSMI MCR ranges as "INSTANCE0"
Early versions of the B-spec originally indicated that Xe3p_XPC had two
ranges of PSMI registers requiring MCR steering (one starting at 0xB500,
one starting at 0xB600), and that reads of registers in these ranges
required different grpid values to ensure that a non-terminated value is
obtained. A late-breaking spec update has simplified this; both ranges
can be safely steered to grpid=0 for reads.
Drop the "PSMI19" replication type and related code, and consolidate
both register ranges into a single entry in the "INSTANCE0" steering
table.
Add platform definition and PCI IDs for Crescent Island.
Other platforms use INTEL_VGA_DEVICE since they have a
PCI_BASE_CLASS_DISPLAY class. This is not the case for CRI, so just
match on devid, which should be sufficient.
Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Link: https://lore.kernel.org/r/20251021-cri-v1-1-bf11e61d9f49@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Matthew Auld [Wed, 22 Oct 2025 16:38:35 +0000 (17:38 +0100)]
drm/xe/migrate: support MEM_COPY instruction
Make this the default on xe2+ when doing a copy. This has a few
advantages over the exiting copy instruction:
1) It has a special PAGE_COPY mode that claims to be optimised for
page-in/page-out, which is the vast majority of current users.
2) It also has a simple BYTE_COPY mode that supports byte granularity
copying without any restrictions.
With 2) we can now easily skip the bounce buffer flow when copying
buffers with strange sizing/alignment, like for memory_access. But that
is left for the next patch.
v2 (Matt Brost):
- Use device info to check whether device should use the MEM_COPY
path. This should fit better with making this a configfs tunable.
- And with that also keep old path still functional on xe2 for possible
experimentation.
- Add a define for PAGE_COPY page-size.
v3 (Matt Brost):
- Fallback to an actual linear copy for pitch=1.
- Also update NVL.
Matthew Auld [Wed, 22 Oct 2025 16:38:34 +0000 (17:38 +0100)]
drm/xe/migrate: trim batch buffer sizing
We have an extra two dwords, but it looks like we should only need one
for the extra bb_end. Likely this is just leftover from back when the
arb handling was moved into the ring programming.
Matthew Auld [Wed, 22 Oct 2025 16:38:33 +0000 (17:38 +0100)]
drm/xe/migrate: fix batch buffer sizing
In xe_migrate_vram() the copy can straddle page boundaries, so the len
might look like a single page, but actually accounting for the offset
within the page we will need to emit more than one PTE. Otherwise in
some cases the batch buffer will be undersized leading to warnings
later. We already have npages so use that instead.
Matthew Auld [Wed, 22 Oct 2025 16:38:32 +0000 (17:38 +0100)]
drm/xe/migrate: fix chunk handling for 2M page emit
On systems with PAGE_SIZE > 4K the chunk will likely be rounded down to
zero, if say we have single 2M page, so one huge pte, since we also try
to align the chunk to PAGE_SIZE / XE_PAGE_SIZE, which will be 16 on 64K
systems. Make the ALIGN_DOWN conditional for 4K PTEs where we can
encounter gpu_page_size < PAGE_SIZE.
Matthew Auld [Wed, 22 Oct 2025 16:38:31 +0000 (17:38 +0100)]
drm/xe/migrate: rework size restrictions for sram pte emit
We allow the input size to not be aligned to PAGE_SIZE, which leads to
various bugs in build_pt_update_batch_sram() for PAGE_SIZE > 4K systems.
For example if ptes is exactly one gpu_page_size then the chunk size is
rounded down to zero. The simplest fix looks to be forcing PAGE_SIZE
aligned inputs.
Matthew Auld [Wed, 22 Oct 2025 16:38:30 +0000 (17:38 +0100)]
drm/xe/migrate: fix offset and len check
Restriction here is pitch of 4bytes to match pixel width (32b), and hw
restriction where src and dst must be aligned to 64bytes. If any of that
is not possible then we need a bounce buffer.
Matthew Brost [Wed, 22 Oct 2025 00:55:38 +0000 (17:55 -0700)]
drm/xe: Avoid PM wake reference during VF migration
Virtual Functions (VFs) do not use runtime PM. Avoid taking PM
references during VF migration, as lockdep may get confused—VF migration
occurs in the reclaim path, and waking a PM reference can trigger memory
allocation warnings.
Matthew Brost [Wed, 22 Oct 2025 00:55:37 +0000 (17:55 -0700)]
drm/xe: Do not wake device during a GT reset
Waking the device during a GT reset can lead to unintended memory
allocation, which is not allowed since GT resets occur in the reclaim
path. Prevent this by holding a PM reference while a reset is in flight.
Tomasz Lis [Tue, 21 Oct 2025 22:48:17 +0000 (00:48 +0200)]
drm/xe/vf: Do not disable VF migration on ATS-M
Our current support for the VF migration depends on the availability
of the MEMIRQ rather than specific graphics version 20.
Relax our early migration support checks to allow also use some older
platforms like ATS-M for experiments and testing.
Do not allow ADL, as supporting VF migration through MMIO interrupts
would require additional changes in order to achieve reliability.
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-5-tomasz.lis@intel.com
Tomasz Lis [Tue, 21 Oct 2025 22:48:16 +0000 (00:48 +0200)]
drm/xe: Assert that VF will never use fixed placement of BOs
Most BOs do not care at which offset they will be accessed within
GGTT or PPGTT. The few which do care, should be only created
on PF, and mapped within GGTT. On VFs, mapping at fixed offset
is prohibited, as each VF is granted access to a range of
GGTT address space.
Since fixed addresses of GGTT mapping can only be used on PF,
add an assert which makes sure no attempt of fixed placement
will happen for a driver probed on a VF.
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-4-tomasz.lis@intel.com
Tomasz Lis [Tue, 21 Oct 2025 22:48:14 +0000 (00:48 +0200)]
drm/xe/vf: Revert logic of vf.migration.enabled
Convert `enabled` property into `disabled`.
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20251021224817.1593817-2-tomasz.lis@intel.com
Gustavo Sousa [Mon, 20 Oct 2025 23:45:57 +0000 (20:45 -0300)]
drm/xe/tests/pci: Check dma_mask_size, va_bits and vm_max_level
Members dma_mask_size, va_bits and vm_max_level of struct xe_device_desc
are all expected to be non-zero. Add checks for that in
check_platform_desc().
Gustavo Sousa [Mon, 20 Oct 2025 23:45:56 +0000 (20:45 -0300)]
drm/xe/tests/pci: Convert GT count check to general device check
We already have check_graphics_ip() and check_media_ip() as general
functions to check the IP descriptors. The check in
check_platform_gt_count() is simple enough such that we can convert the
function to a more general device check. In an upcoming change, we will
also add some checks for other members of struct xe_device_desc. As
such, rename check_platform_gt_count() to check_platform_desc().
While at it, use inline (unsigned int) casting of max_gt_per_tile to
keep checks for each member localized; and use KUNIT_EXPECT_*() variants
of the macros to allow multiple issues to be reported.
Shuicheng Lin [Thu, 16 Oct 2025 22:55:07 +0000 (22:55 +0000)]
drm/xe: Fix stolen size check to allow equal WOPCM size
On some platforms without dedicated stolen memory, the calculated
stolen size may be exactly equal to the WOPCM size. The current
assertion incorrectly requires it to be strictly greater, causing
a false failure. Relax the check to allow equality.
Fixes: 65369b8e2961 ("drm/xe: Change return type of detect_bar2_dgfx() from s64 to u64") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6359 Cc: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20251016225506.2256127-2-shuicheng.lin@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/xe/xe3p_lpm: Add special check in Media GT for Main GAMCTRL
For Xe3p arch some subunits of an IP may be different. The GMD_ID
register returns the Xe3p arch and dedicates the reserved field to mark
possible subunit differences. Generally this is an under-the-hood
implementation detail that drivers don't need to worry about, but the
new Main_GAMCTRL may be enabled or not depending on those.
Those reserved bits are described for Xe3p as: "If Zero, No special case
to be handled. If Non-Zero, special case to be handled by Software
agent.". That special case is defined per Arch. So if media version is
35, also check the additional reserved bits. To avoid confusion with the
usual meaning of "reserved", define them as GMD_ID_SUBIP_FLAG_MASK.
Starting from Xe3p, there are two different copies of some of the GAM
registers: the traditional MCR variant at their old locations, and a
new unicast copy known as "main_gamctrl." The Xe driver doesn't use
these registers directly, but we need to instruct the GuC on which set
it should use. Since the new, unicast registers are preferred (since
they avoid the need for unnecessary MCR synchronization), set a new GuC
feature flag, GUC_CTL_MAIN_GAMCTRL_QUEUES to convey this decision. A
new helper function, xe_guc_using_main_gamctrl_queues(), is added for
use in the 3 independent places that need to handle configuration of the
new reporting queues.
The mmio write to enable the main gamctl is only done during the general
GuC upload. The gamctrl registers are not accessed by the GuC during
hwconfig load.
Last, the ADS blob for communicating the queue addresses contains both a
DPA and GGTT offset. The GuC documentation states that DPA is now MBZ
when using the MAIN_GAMCTRL queues.
Harish Chegondi [Fri, 17 Oct 2025 02:26:43 +0000 (19:26 -0700)]
drm/xe/xe3p: Add xe3p EU stall data format
Starting with Xe3p, IP address in EU stall data increases to 61 bits.
While at it, re-order the if-else ladder so the officially supported
platforms come before PVC.
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Harish Chegondi <harish.chegondi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-24-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Matt Roper [Fri, 17 Oct 2025 02:26:42 +0000 (19:26 -0700)]
drm/xe/xe3p_xpc: Setup PAT table
Xe3p_XPC IP requires a new PAT table; note that this table has one fewer
column than the Xe2/Xe3 tables since compression is not supported.
There's also no "WT" entry (which we wouldn't have used on a platform
without display anyway).
Bspec: 71582 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-23-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Matt Roper [Fri, 17 Oct 2025 02:26:41 +0000 (19:26 -0700)]
drm/xe/xe3p_xpc: Skip compression tuning on platforms without flatccs
The compression overfetch tuning settings only apply to platforms that
support FlatCCS. In Xe3p_XPC (and any future IPs that also lack
compression) some of the registers being adjusted by this tuning will
not exist or may have been repurposed for something else, so we should
take care not to try to program them.
Note that our xe_rtp_match_has_flatccs() function will also return false
on platforms that do have FlatCCS in the hardware design, but have
compression manually disabled in the BIOS. On such platforms the
registers still exist (and it would be fine to continue programming
them), but they would have no effect, so skipping that tuning is also
safe.
Lucas De Marchi [Fri, 17 Oct 2025 02:26:40 +0000 (19:26 -0700)]
drm/xe/xe3p_xpc: Add support for compute walker for non-MSIx
Current implementation of compute walker has dependency on GPU/SW Stack
which requires SW/UMD to wait for event from KMD to indicate
PIPE_CONTROL interrupt was done. This created latency on SW stack.
This feature adds support to generate completion interrupt from GPGPU
walker which does not support MSIx and avoid software using Pipe control
drain/idle latency.
The only thing needed for the kernel driver to do here is to wakeup the
thread waiting on the ufence, which is already handled by the irq
handler. Before waiting on this event, the userspace side can opt-in to
this interrupt being generated by the HW by selecting the flag in the
POST_SYNC_DATA_2 substructure's dw0[3] of COMPUTE_WALKER_2 instruction.
Bspec: 62346, 74334 Suggested-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: S A Muqthyar Ahmed <syed.abdul.muqthyar.ahmed@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-21-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Lucas De Marchi [Fri, 17 Oct 2025 02:26:39 +0000 (19:26 -0700)]
drm/xe/irq: Check fuse mask for media engines
Just like the other engines, check xe_hw_engine_mask_per_class() for VCS
and VECS to account for architectural availability of those registers.
With that, all the possibly available media engines can have their
interrupts enabled.
Lucas De Marchi [Fri, 17 Oct 2025 02:26:38 +0000 (19:26 -0700)]
drm/xe/irq: Rename bits used with all engines
Two bit fields have similar functionality across the interrupt vectors
but are named "RENDER". Rename them to follow the bspec more closely and
clear any confusion when using them for other engines.
Bspec: 62353, 62354, 62355, 62346, 62345, 63341 Suggested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-19-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Lucas De Marchi [Fri, 17 Oct 2025 02:26:37 +0000 (19:26 -0700)]
drm/xe/irq: Split irq mask per engine class
Each engine class has a different bitfield structure in the hw. We've
been just using a common mask for all of them, but this means that we
could inadvertently set a wrong bit in one class while enabling
something in another. Split them to make it more future proof.
Lucas De Marchi [Fri, 17 Oct 2025 02:26:36 +0000 (19:26 -0700)]
drm/xe/irq: Rename fuse mask variables
It's confusing to refer to some masks as the interrupt masks and others
as the fuse masks. Rename the fuse one to make it clearer.
Note that the most important role they play here is that the call
to xe_hw_engine_mask_per_class() will not only limit the engines
according to the fuses, but also by what is available in the specific
architecture - the latter is more important information to know what
interrupts should be enabled. Add a comment about that.
Matt Roper [Fri, 17 Oct 2025 02:26:35 +0000 (19:26 -0700)]
drm/xe/xe3p_xpc: Add MCR steering
Xe3p_XPC's steering has a few changes from Xe3. Aside from
minor changes to the XeCore (the new name for what used to be "DSS") and
INSTANCE0 tables, different rules apply to different subranges of type
"GAM." Certain GAM subranges require steering to grp/instance (0,0)
(and thus use the INSTANCE0 table), while others require special
steering to (1,0) instead. Similarly, there are multiple classes of
"PSMI" steering, with some requiring steering to (0,0) while others
require (19,0).
There are some ranges in Bspec missing the termination. Add a TODO
comment so they can eventually be updated.
Fei Yang [Fri, 17 Oct 2025 02:26:34 +0000 (19:26 -0700)]
drm/xe/xe3p_xpc: Add L3 bank mask
Expose L3 bank mask through topology query interface.
In Xe3p_XPC, MIRROR_L3BANK_ENABLE represents the full L3 bank mask (not
just a per-node mask), and each bit represents a single bank. With that
there's no extra complexity to calculate the L3 bank mask like there was
in previous platforms.
Wang Xin [Fri, 17 Oct 2025 02:26:29 +0000 (19:26 -0700)]
drm/xe/xe3p: Dump CSMQDEBUG register
The CSMQDEBUG is useful for the development of MQ feature. Start dumping
the debug register.
Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Wang Xin <x.wang@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-10-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Wang Xin [Fri, 17 Oct 2025 02:26:28 +0000 (19:26 -0700)]
drm/xe: Dump CURRENT_LRCA register
Add CURRENT_LRCA to register dump to help debugging.
Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Wang Xin <x.wang@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-9-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Matt Roper [Fri, 17 Oct 2025 02:26:25 +0000 (19:26 -0700)]
drm/xe/xe3p_lpm: Handle MCR steering
Xe3p_LPM's MCR steering has the same ranges and behavior as Xe3_LPM.
However one register range that was reserved on Xe3_LPM has now become a
unicast range (0x384200-0x38427F), so we need to stop consolidating the
adjacent MCR ranges into a single table entry in the table. With this
change to the Xe3_LPM table, we can continue to use the same table for
both IP families.
While we're touching this table, take the opportunity to fix a
whitespace mistake and clarify that one of the other consolidated range
entries includes a reserved range.
Bspec: 76445 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-6-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Lucas De Marchi [Fri, 17 Oct 2025 02:26:23 +0000 (19:26 -0700)]
drm/xe: Add GT_VER() to check version specific to gt type
In some situations we will need to check the version of the specific gt
being passed as argument, not if the device has a certain graphics/media
version.
This is extracted from a patch by Balasubramani Vivekanandan that
may need some rework, but this helper is still useful for other enabling
parts of Xe3p.
The warning was added for a condition that never triggered even for
platforms prior to Xe2. It's not supported in Xe2 and in Xe3p the
register is removed from the main GT. Just drop the entire function as
it doesn't bring any benefit.
Bspec: 62395 Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
[ Drop the entire check for CTC_MODE ] Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20251016-xe3p-v3-3-3dd173a3097a@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Michal Wajdeczko [Wed, 15 Oct 2025 09:12:09 +0000 (11:12 +0200)]
drm/xe/pf: Allow to restore auto-provisioning mode
After doing tweaks to the VFs provisioning we may want to restore
back the auto-provisioning mode. Allow that unless VFs are still
enabled. This can be also used to release all VFs resources.
Lukasz Laguna [Thu, 16 Oct 2025 12:22:33 +0000 (14:22 +0200)]
drm/xe/pf: Always expose VRAM provisioning data on discrete GPUs
Currently, VRAM provisioning data is only exposed if the device supports
LMTT. While it should not be possible to modify VRAM provisioning on
platforms without LMTT, it is still useful to be able to read the VRAM
provisioning data on all discrete GPU platforms.
Expose the VRAM debugfs attributes whenever running on dGFX, adjusting
file permissions to read only when LMTT is not available.
Thomas Hellström [Wed, 15 Oct 2025 17:07:26 +0000 (19:07 +0200)]
drm/xe/uapi: Hide the madvise autoreset behind a VM_BIND flag
The madvise implementation currently resets the SVM madvise if the
underlying CPU map is unmapped. This is in an attempt to mimic the
CPU madvise behaviour. However, it's not clear that this is a desired
behaviour since if the end app user relies on it for malloc()ed
objects or stack objects, it may not work as intended.
Instead of having the autoreset functionality being a direct
application-facing implicit UAPI, make the UMD explicitly choose
this behaviour if it wants to expose it by introducing
DRM_XE_VM_BIND_FLAG_MADVISE_AUTORESET, and add a semantics
description.
v2:
- Kerneldoc fixes. Fix a commit log message.
Fixes: a2eb8aec3ebe ("drm/xe: Reset VMA attributes to default in SVM garbage collector") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: "Falkowski, John" <john.falkowski@intel.com> Cc: "Mrozek, Michal" <michal.mrozek@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20251015170726.178685-2-thomas.hellstrom@linux.intel.com
Thomas Hellström [Wed, 15 Oct 2025 17:07:25 +0000 (19:07 +0200)]
drm/xe: Retain vma flags when recreating and splitting vmas for madvise
When splitting and restoring vmas for madvise, we only copied the
XE_VMA_SYSTEM_ALLOCATOR flag. That meant we lost flags for read_only,
dumpable and sparse (in case anyone would call madvise for the latter).
Instead, define a mask of relevant flags and ensure all are replicated,
To simplify this and make the code a bit less fragile, remove the
conversion to VMA_CREATE flags and instead just pass around the
gpuva flags after initial conversion from user-space.
Fixes: a2eb8aec3ebe ("drm/xe: Reset VMA attributes to default in SVM garbage collector") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251015170726.178685-1-thomas.hellstrom@linux.intel.com
Matthew Brost [Wed, 15 Oct 2025 12:03:20 +0000 (14:03 +0200)]
drm/gpusvm, drm/xe: Allow mixed mappings for userptr
Compute kernels often issue memory copies immediately after completion.
If the memory being copied is an SVM pointer that was faulted into the
device and then bound via userptr, it is undesirable to move that
memory. Worse, if userptr is mixed between system and device memory, the
bind operation may be rejected.
Xe already has the necessary plumbing to support userptr with mixed
mappings. This update modifies GPUSVM's get_pages to correctly locate
pages in such mixed mapping scenarios.
v2:
- Rebase (Thomas Hellström)
v3:
- Remove Fixes tag.
v4:
- Break out from series since the other patch was merged.
- Update patch subject, ensure dri-devel and Maarten are CC'd.
Cc: Maarten Lankhorst <maarten.lankhorst@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20251015120320.176338-1-thomas.hellstrom@linux.intel.com Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Matthew Auld [Fri, 10 Oct 2025 15:24:58 +0000 (16:24 +0100)]
drm/xe/evict: drop bogus assert
This assert can trigger here with non pin_map users that select
LATE_RESTORE, since the vmap is allowed to be NULL given that
save/restore can now use the blitter instead. The check here doesn't
seem to have much value anymore given that we no longer move pinned
memory, so any existing vmap is left well alone, and doesn't need to be
recreated upon restore, so just drop the assert here.
Fixes: 86f69c26113c ("drm/xe: use backup object for pinned save/restore") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6213 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/20251010152457.177884-2-matthew.auld@intel.com
Matthew Auld [Fri, 10 Oct 2025 16:20:21 +0000 (17:20 +0100)]
drm/xe/migrate: don't misalign current bytes
If current bytes exceeds the max copy size, ensure the clamped size
still accounts for the XE_CACHELINE_BYTES alignment, otherwise we
trigger the assert in xe_migrate_vram with the size now being out of
alignment.
Matt Roper [Mon, 13 Oct 2025 20:10:06 +0000 (13:10 -0700)]
drm/xe/sriov: Disable SR-IOV if primary GT is disabled via configfs
SR-IOV operation relies on the primary GT's GuC to operate (in both PF
and VF mode). Don't enable the .has_sriov flag if the primary-GT was
disabled by configfs.
v2:
- Move handling to xe_info_init(). (Michal)
v3:
- Just update the .has_sriov flag in xe_info_init_early(). (Michal)
v4:
- Drop unnecessary comment. (Michal)
- Flip condition order for consistency with other checks. (Michal)
Matt Roper [Mon, 13 Oct 2025 20:10:05 +0000 (13:10 -0700)]
drm/xe/configfs: Add attribute to disable GT types
Preventing the driver from initializing GTs of specific type(s) can be
useful for debugging and early hardware bringup. Add a configfs
attribute to allow this kind of control for debugging.
With today's platforms and software design, this configuration setting
is only effective for disabling the media GT since the driver currently
requires that there always be a primary GT to probe the device. However
this might change in the future --- in theory it should be possible
(with some additional driver work) to allow an igpu device to come up
with only the media GT and no primary GT. Or to allow an igpu device to
come up with no GTs at all (for display-only usage). A primary GT will
likely always be required on dgpu platforms because we rely on the BCS
engines inside the primary GT for various vram operations.
v2:
- Expand/clarify kerneldoc for configfs attribute. (Gustavo)
- Tighten type usage in gt_types[] structure. (Gustavo)
- Adjust string parsing/name matching to match exact GT names and not
accept partial names. (Gustavo)
v3:
- Switch to scope-based cleanup in gt_types_allowed_store() to fix a
leak if the device is already bound. (Gustavo)
- Switch configfs lookup interface to two boolean functions that
specify whether primary/media are supported rather than one function
that returns a mask. This is simpler to use and understand.
v4:
- Rename xe_configfs_*_gt_supported to xe_configfs_*_gt_allowed for
consistency with configfs interface and other functions. (Gustavo)
- Simplify boolean check in xe_configfs_*_gt_allowed. (Michal)
- Use xe_info() for message printing. (Michal)
- Use guard() instead of scoped_guard(). (Michal)
- Make new functions take 'struct pci_dev' for consistency with other
configfs lookup functions. (Michal)
Matt Roper [Mon, 13 Oct 2025 20:10:04 +0000 (13:10 -0700)]
drm/xe: Break GT setup out of xe_info_init()
xe_info_init() is getting a bit long and hard to follow. Break the
allocation and basic initialization of the xe_gt structures out to their
own functions.
v2:
- Rename new functions from init_* to alloc_*. (Gustavo)
- Move early NULL return of media GT before allocation. (Gustavo)
Matt Roper [Mon, 13 Oct 2025 20:10:03 +0000 (13:10 -0700)]
drm/xe: Don't check BIOS-disabled FlatCCS if primary GT is disabled
If the primary is GT is disabled via configfs, we can't read the GT
registers that would tell us whether the BIOS has disabled FlatCCS on a
platform that would otherwise have it; we'll just proceed as if the
FlatCCS is still enabled. This is similar to the situation seen by
SRIOV VFs and doesn't cause any functional problems since the hardware
will simply drop writes to the CCS region and reads will always come
back as 0 (indicating uncompressed data). We'll simply miss out on the
chance to avoid some unnecessary overhead during BO creation and
migration.
Matt Roper [Mon, 13 Oct 2025 20:10:01 +0000 (13:10 -0700)]
drm/xe: Correct lineage for Wa_22014953428 and only check with valid GT
Wa_22014953428 was incorrectly labelled with a release-specific ID
number rather than the cross-platform lineage number; fix that.
Also check that the GT is not NULL before trying to lookup the
workaround in it. Since this workaround only applies to DG2 discrete
GPUs (where the primary GT cannot be disabled), no coverage is lost.
Matt Roper [Mon, 13 Oct 2025 20:10:00 +0000 (13:10 -0700)]
drm/xe: Bypass Wa_14018094691 when primary GT is disabled
Don't try to lookup Wa_14018094691 on a NULL GT when the primary GT is
disabled. Since this whole workaround centers around mid-thread
preemption behavior, the workaround isn't relevant if the primary GT
(where the engines that can do MTP live) is disabled.
Matt Roper [Mon, 13 Oct 2025 20:09:59 +0000 (13:09 -0700)]
drm/xe/rtp: Pass xe_device parameter to FUNC matches
FUNC matches in RTP only pass the GT and hwe, preventing them from being
used effectively in device workarounds. Add an additional xe_device
parameter so that we can use them in device workarounds where a GT may
not be available.
Matt Roper [Mon, 13 Oct 2025 20:09:58 +0000 (13:09 -0700)]
drm/xe: Handle Wa_22010954014 and Wa_14022085890 as device workarounds
When Wa_22010954014 and Wa_14022085890 were first implemented, we didn't
have a device workaround infrastructure so we hacked them into the GT
workaround list. Now that we have proper device workaround support,
move them to the proper place. Note that Wa_14022085890 specifically
applies to BMG-G21 platforms, so this requires defining a BMG
subplatform to capture the correct subset of device IDs.
Matt Roper [Mon, 13 Oct 2025 20:09:57 +0000 (13:09 -0700)]
drm/xe/irq: Don't try to lookup engine masks for non-existent primary GT
If the primary GT is disabled via configfs, we shouldn't try to access
it to lookup BCS/CCS engine masks. For the purposes of IRQ reset (which
masks & disables interrupts in an sgunit register), assume all possible
instances are present.
Matt Roper [Mon, 13 Oct 2025 20:09:56 +0000 (13:09 -0700)]
drm/xe: Make display part of Wa_22019338487 a device workaround
The display part of Wa_22019338487 (i.e., avoiding use of stolen memory)
is using a platform test rather than an graphics/media IP test. Since
this workaround is focused on non-GT uses of stolen memory, it makes
sense that we'd want to still apply the workaround on affected platforms
even if the GTs themselves are disabled via configfs.
Matt Roper [Mon, 13 Oct 2025 20:09:55 +0000 (13:09 -0700)]
drm/xe: Check for primary GT before looking up Wa_22019338487
If the primary GT is disabled via configfs, we need to make sure that we
don't search for this workaround on a NULL xe_gt pointer. Since we can
disable the primary GT only on igpu platforms, the media GT is the one
we'd want to check anyway for this workaround.
The ternary operators in ggtt_update_access_counter() were getting a bit
long/complicated, so rewrite them with regular if/else statements.
While we're at it, throw in a couple extra assertions to make sure that
we're truly picking the expected GT according to igpu/dgpu type.
v2:
- Adjust indentation/wrapping; it's easier to read this with longer,
unwrapped lines. (Lucas)
- Tweak wording of commit message to remove ambiguity. (Gustavo)
Matt Roper [Mon, 13 Oct 2025 20:09:54 +0000 (13:09 -0700)]
drm/xe/pmu: Initialize PMU event types based on first available GT
GT ID#0 (primary GT on tile 0) may not always be available if the
primary GT has been disabled via configfs. Instead use the first
available GT when determining which PMU events are supported. If there
are no GTs, then don't advertise any GT-related events.
Matt Roper [Mon, 13 Oct 2025 20:09:53 +0000 (13:09 -0700)]
drm/xe/query: Report hwconfig size as 0 if primary GT is disabled
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.
Matt Roper [Mon, 13 Oct 2025 20:09:51 +0000 (13:09 -0700)]
drm/xe: Move primary GT allocation from xe_tile_init_early to xe_tile_init
During the early days of the Xe driver, there were cases where we
accessed some fields in the primary GT's xe_gt structure before the GT
itself was formally initialized; this required that the structure itself
be allocated during xe_tile_init_early(). A lot of refactoring of the
device probe has happened since that time and there's no longer a need
to allocate the primary GT early. Move the allocation into
xe_info_init() where GT initialization happens and where we're doing the
allocation of the media GT.
v2:
- Only make this change after a separate patch to perform VF GMD_ID
lookup with a dummy GT instead of xe_root_mmio_gt().
Matt Roper [Mon, 13 Oct 2025 20:09:50 +0000 (13:09 -0700)]
drm/xe: Read VF GMD_ID with a specifically-allocated dummy GT
SRIOV VF initialization has a bit of a chicken and egg design problem.
Determining the IP version of the graphics and media IPs can't be done
via direct register reads as it is on PF or native and instead requires
querying the GuC. However initialization of the GT, including its GuC,
needs to wait until after we know the IP versions so that the proper
initialization steps for the platform/IP are followed.
Currently the (somewhat hacky) solution is to manually fill out just
enough fields in tile 0's primary GT structure to make it look as if the
GT has been initialized so that the GuC can be partially initialized and
queried to obtain the GMD_ID values. When the GT gets properly
initialized during the regular flows, the hacked-up values will get
overwritten as part of the general initialization flows.
Rather than using tile 0's primary GT structure to hold the hacked up
values for querying every GT on every tile, instead allocate a dedicated
dummy structure. This will allow us to move the tile->primary_gt's
allocation to a more consistent place later in the initialization flow
in future patches (i.e., we shouldn't even allocate this GT structure if
the GT is disabled/unavailable). It also helps ensure there can't be
any accidental leakage of initialization or state between the dummy
initialization for GMD_ID and the real driver initialization of the GT.
v2:
- Initialize gt->tile for temporary GT. (CI, Michal)
- Use scope-based cleanup handler to free temp GT. (Michal)
- Propagate actual error code from xe_gt_sriov_vf_bootstrap() rather
than just setting IP version to 0.0 now that read_gmdid() can return
an error. (Michal)
v3:
- Explicitly initialize gt to NULL, just in case something else gets
inserted before the kzalloc() in the future. (Lucas)
Matt Roper [Mon, 13 Oct 2025 20:09:49 +0000 (13:09 -0700)]
drm/xe: Move 'has_flatccs' flag back to platform descriptor
FlatCCS presence/absence is a flag that should be tracked at the
platform level rather than the IP level. FlatCCS affects the
device-wide memory initialization and reservations so its effects are
not confined to a single IP block or GT. This is also a trait that
should be tied to the platform even if the graphics IP itself is not
present (e.g., if we disable the primary GT via configfs).
Matt Roper [Mon, 13 Oct 2025 20:09:48 +0000 (13:09 -0700)]
drm/xe: Move 'vram_flags' flag back to platform descriptor
Restrictions and requirements on VRAM alignment are something that
should be tracked at the platform level rather than the IP level. Even
when mixing and matching various graphics, media, and display IP blocks,
the platform as a whole has to have consistent memory allocation
handling. This is also a trait that should be tied to the platform even
if the graphics IP itself is not present (e.g., if we disable the
primary GT via configfs).
Matt Roper [Mon, 13 Oct 2025 20:09:47 +0000 (13:09 -0700)]
drm/xe: Move 'vm_max_level' flag back to platform descriptor
The number of page table levels for PPGTT virtual addresses is something
that should be tracked at the platform level rather than the IP level.
Even when mixing and matching various graphics, media, and display IP
blocks, the platform as a whole has to have consistent page table
handling. This is also a trait that should be tied to the platform even
if the graphics IP itself is not present (e.g., if we disable the
primary GT via configfs).
v2:
- Drop default value of 4 and explicitly set the value in each platform
descriptor. (Lucas)
v3:
- Drop outdated code comment and commit message paragraph about default
value. (Gustavo)
v4:
- Add missing setting for tgl_desc. (Gustavo)
Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20251013200944.2499947-29-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Matt Roper [Mon, 13 Oct 2025 20:09:46 +0000 (13:09 -0700)]
drm/xe: Move 'va_bits' flag back to platform descriptor
The number of virtual address bits is something that should be tracked
at the platform level rather than the IP level. Even when mixing and
matching various graphics, media, and display IP blocks, the platform as
a whole has to have consistent page table handling. This is also a
trait that should be tied to the platform even if the graphics IP itself
is not present (e.g., if we disable the primary GT via configfs).
v2:
- Drop the default value of 48 and explicitly set it in each relevant
descriptor. (Lucas, Michal)
v3:
- Drop an outdated comment about default value. (Michal)
Matt Roper [Mon, 13 Oct 2025 20:09:45 +0000 (13:09 -0700)]
drm/xe: Drop GT parameter to xe_display_irq_postinstall()
Display interrupt handling has no relation to GT(s) on the platforms
supported by the Xe driver. We only call xe_display_irq_postinstall
with the first tile's primary GT, so the single condition that uses the
GT pointer within the function always evaluates to true. Drop the
unnecessary parameter and the condition.
Matt Roper [Mon, 13 Oct 2025 20:09:44 +0000 (13:09 -0700)]
drm/xe/huc: Adjust HuC check on primary GT
The HuC initialization code determines whether a platform can have a HuC
on the primary GT by checking whether tile->media_gt is NULL; old Xe1
platforms that combined render+media into a single GT will always have a
NULL media_gt pointer. However once we allow media to be disabled via
configfs, there will also be cases where tile->media_gt is NULL on more
modern platforms, causing this condition to behave incorrectly.
To handle cases where media gets disabled via configfs (or theoretical
cases where media is truly fused off in hardware), change the condition
to consider the graphics version of the primary GT; only the old Xe1
platforms with graphics versions 12.55 or earlier should try to
initialize a HuC on the primary GT.
Matt Roper [Mon, 13 Oct 2025 15:30:15 +0000 (08:30 -0700)]
drm/xe/kunit: Fix kerneldoc for parameterized tests
Kunit's generate_params() was recently updated to take an additional
test context parameter. Xe's IP and platform parameter generators were
updated accordingly at the same time, but the new parameter was not
added to the functions' kerneldoc, resulting in the following warnings:
Warning: drivers/gpu/drm/xe/tests/xe_pci.c:78 function parameter 'test' not described in 'xe_pci_fake_data_gen_params'
Warning: drivers/gpu/drm/xe/tests/xe_pci.c:254 function parameter 'test' not described in 'xe_pci_graphics_ip_gen_param'
Warning: drivers/gpu/drm/xe/tests/xe_pci.c:278 function parameter 'test' not described in 'xe_pci_media_ip_gen_param'
Warning: drivers/gpu/drm/xe/tests/xe_pci.c:302 function parameter 'test' not described in 'xe_pci_id_gen_param'
Warning: drivers/gpu/drm/xe/tests/xe_pci.c:390 function parameter 'test' not described in 'xe_pci_live_device_gen_param'
5 warnings as errors
Document the new parameter to eliminate the warnings and make CI happy.
Thomas Hellström [Fri, 10 Oct 2025 10:41:48 +0000 (12:41 +0200)]
drm/xe/svm: Ensure data will be migrated to system if indicated by madvise.
If the location madvise() is set to
DRM_XE_PREFERRED_LOC_DEFAULT_SYSTEM, the drm_pagemap in the
SVM gpu fault handler will be set to NULL. However there is nothing
that explicitly migrates the data to system if it is already present
in device memory.
In that case, set the device memory owner to NULL to ensure
data gets properly migrated to system on page-fault.
Tomasz Lis [Thu, 9 Oct 2025 17:08:44 +0000 (19:08 +0200)]
drm/xe/ct: Separate waiting for retry from ct send function
The function `guc_ct_send_locked()` is really quite simple, but still
looks complex due to exposed internals. It is sending a message,
and in case of lack of space, waiting for a proper moment to send
a retry.
Clear separation of send function and wait function will help with
readability. This is a cosmetic change only, no functional difference
is expected.
This patch introduces `guc_ct_send_wait_for_retry()`, and uses it to
greatly simplify `guc_ct_send_locked()`.
Matthew Brost [Mon, 13 Oct 2025 03:45:55 +0000 (20:45 -0700)]
drm/xe: Enable 2M pages in xe_migrate_vram
Using 2M pages in xe_migrate_vram has two benefits: we issue fewer
instructions per 2M copy (1 vs. 512), and the cache hit rate should be
higher. This results in increased copy engine bandwidth, as shown by
benchmark IGTs.
Enable 2M pages by reserving PDEs in the migrate VM and using 2M pages
in xe_migrate_vram if the DMA address order matches 2M.
v2:
- Reuse build_pt_update_batch_sram (Stuart)
- Fix build_pt_update_batch_sram for PAGE_SIZE > 4K
v3:
- More fixes for PAGE_SIZE > 4K, align chunk, decrement chunk as needed
- Use stack incr var in xe_migrate_vram_use_pde (Stuart)
v4:
- Split PAGE_SIZE > 4K fix out in different patch (Stuart)
Matthew Brost [Mon, 13 Oct 2025 03:45:54 +0000 (20:45 -0700)]
drm/xe: Fix build_pt_update_batch_sram for non-4K PAGE_SIZE
The build_pt_update_batch_sram function in the Xe migrate layer assumes
PAGE_SIZE == XE_PAGE_SIZE (4K), which is not a valid assumption on
non-x86 platforms. This patch updates build_pt_update_batch_sram to
correctly handle PAGE_SIZE > 4K by programming multiple 4K GPU pages per
CPU page.
Shuicheng Lin [Fri, 10 Oct 2025 17:25:29 +0000 (17:25 +0000)]
drm/xe/guc: Check GuC running state before deregistering exec queue
In normal operation, a registered exec queue is disabled and
deregistered through the GuC, and freed only after the GuC confirms
completion. However, if the driver is forced to unbind while the exec
queue is still running, the user may call exec_destroy() after the GuC
has already been stopped and CT communication disabled.
In this case, the driver cannot receive a response from the GuC,
preventing proper cleanup of exec queue resources. Fix this by directly
releasing the resources when GuC is not running.
Here is the failure dmesg log:
"
[ 468.089581] ---[ end trace 0000000000000000 ]---
[ 468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535)
[ 468.090558] pci 0000:03:00.0: [drm] GT0: total 65535
[ 468.090562] pci 0000:03:00.0: [drm] GT0: used 1
[ 468.090564] pci 0000:03:00.0: [drm] GT0: range 1..1 (1)
[ 468.092716] ------------[ cut here ]------------
[ 468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe]
"
v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled().
As CT may go down and come back during VF migration.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20251010172529.2967639-2-shuicheng.lin@intel.com
projects / thirdparty / kernel / linux.git / log
