| Age | Commit message (Collapse) | Author |
|---|
|
# Conflicts:
# drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
# net/ceph/osd_client.c
|
|
Pass watchpoint addresses through amdgpu_mes_set_shader_debugger() so
MES programs TCP_WATCH registers at dispatch time.
Assisted-by: claude-code:claude-sonnet-4
Signed-off-by: David Belanger <david.belanger@amd.com>
Reviewed-by: Michael Chen <michael.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
PTL will limit access to specific registers. Instead of silently
dropping these attempts, log them in dmesg for reference. Also add a
dev_debug option to show what pasid/addr/packet type failed.
v2: Make sure to guard it by MEC v195, and move enable call into
ptl_hw_init function
Signed-off-by: Kent Russell <kent.russell@amd.com>
Reviewed-by: Perry Yuan <perry.yuan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
reserve_mem_limit() computes available VRAM as
vram_size - reserved - vram_pin_size - kfd.vram_used
However, kfd.vram_used already includes BOs that are later pinned.
Pinning does not consume extra VRAM. Subtracting
vram_pin_size counts those bytes twice and causes fake-OOM
while VRAM is still free.
Reuse get_available_memory() in reserve_mem_limit(). Move
ALIGN_DOWN to the ioctl so the userspace ABI is unchanged. The
VRAM counter is a parameter: the ioctl passes vram_used_aligned[],
the gate passes vram_used[] so a 4K BO is not charged 2MB.
kfd.vram_pinned is only updated in gpuvm_pin_bo(). dma-buf pin
calls amdgpu_bo_pin() only, so the counter stays zero. Update it
from amdgpu_bo_pin() through a KFD helper, on first pin and last
unpin, matching vram_pin_size.
Track per-XCP pins in vram_pin_size_xcp[] and kfd.vram_pinned[].
Pins that are not owned by a single partition go to
vram_pin_size_common, which every partition subtracts.
A KFD VRAM BO always carries a partition, so the KFD credit is only
correct for xcp >= 0. Call the helper for both branches and let it
warn once and skip if that ever stops holding: without the credit the
BO would be subtracted through vram_pin_size_common and never added
back, which is the double counting this patch removes, and
kfd.vram_pinned[] would be indexed out of bounds.
Suggested-by: Philip Yang <Philip.Yang@amd.com>
Signed-off-by: Zhen Han <Zhen.Han@amd.com>
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When a GPU reset takes the reset domain, KFD eviction cannot unmap
user queues: execute_queues_cpsch() fails its trylock with -EIO, so
the queues keep running until the ASIC is reset. The TLB flush is also
skipped while the reset is in progress. If the process unmaps and frees
a BO in that window, its pages are released while a queue can still
access them through stale translations.
On MI300X, munmap() then crashes in free_swap_cache() on a small bogus
page pointer in its mmu_gather batch page:
BUG: unable to handle page fault for address: 0000000000002900
RIP: 0010:free_swap_cache+0x5/0xb0
Call Trace:
free_pages_and_swap_cache+0x3a/0x60
tlb_batch_pages_flush+0x43/0x80
tlb_flush_mmu+0x3d/0x110
zap_pte_range+0x80d/0xcd0
...
do_vmi_align_munmap+0x3e8/0x5b0
do_vmi_munmap+0xdf/0x190
__vm_munmap+0xad/0x180
__x64_sys_munmap+0x1b/0x30
In a traced crash the bogus pointer was the read pointer value of an SDMA
queue the process had just destroyed, at the read pointer's page offset:
the queue's writeback landed in its freed rptr page after the page was
reused as the batch page.
commit f0b4440cdc18 ("drm/amdkfd: Fix mode1 reset crash issue") fixed
this race on process exit by waiting for the reset to complete before
freeing the process's BOs. Free through the ioctl has the same race.
Wait for the reset there too, using the same helper.
Fixes: 9c33e5fd4fb6 ("drm/amdgpu: fix locking scope when flushing tlb")
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: William Palacek <William.Palacek@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Reading the KFD HQD debugfs node (dqm_debugfs_hqds) on a gc_12_1_0 part
oopses with a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: hqd_sdma_dump_v12_1+0x6a [amdgpu]
Call Trace:
dqm_debugfs_hqds+0x2da/0x360 [amdgpu]
kfd_debugfs_hqds_by_device+0x74/0xa0 [amdgpu]
seq_read ... __x64_sys_read
get_sdma_rlc_reg_offset() assumes an interleaved layout where the second
SDMA per XCC lives in a separate SDMA1_HWIP register aperture. On
gc_12_1_0 that aperture does not exist.
Rewrite get_sdma_rlc_reg_offset() to mirror sdma_v7_1_get_reg_offset():
base the offset on adev->reg_offset[GC_HWIP][xcc_id][0] and add the
per-instance SDMA1 offset for the odd instance.
Fixes: 7bd5d763b8e1 ("drm/amdkfd: Add gfx_v12_1_kfd2kgd interface for GFX12_1")
Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When kfd_queue_acquire_buffers() fails, its error path calls
kfd_queue_release_buffers(), which also drops a queue_refcount on the
SVM range at ctx_save_restore_area_address. The SVM range is the last
buffer acquired, and kfd_queue_buffer_svm_get() takes no reference when
it fails, so on every error path this reference was never taken. If
another queue of the process uses that CWSR range, its reference is
dropped instead, and unmapping the range no longer evicts that queue
while its CWSR area is unmapped from the GPU.
On navi31, with queue A using an SVM CWSR range: munmap() of the range
logs
Freeing queue vital buffer 0x..., queue evicted
but after a CREATE_QUEUE that reuses A's CWSR address with an unmapped
write pointer (-EINVAL), the same munmap() leaves A running without the
message.
Only put the BOs on the acquire error path. The warning and the eviction
are back after the failed CREATE_QUEUE.
Fixes: b049504e211e ("drm/amdkfd: Validate user queue svm memory residency")
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The check-and-allocate sequence on pdd->qpd.proc_doorbells is
lockless at every call site of kfd_alloc_process_doorbells():
kfd_get_process_doorbells() (mmap of /dev/kfd),
kfd_ioctl_create_queue() and the CRIU restore path each test the
pointer under different locking (or none), so two racing threads can
both observe NULL and each allocate a doorbell BO and bitmap,
orphaning one allocation and handing the two mappings different
backing pages.
Move the serialization into kfd_alloc_process_doorbells() itself,
using a new per-process-device mutex so all three call sites are
covered regardless of their own locking. The device-global
kfd->doorbell_mutex is not suitable here: it is acquired under
dqm->lock on the kernel-doorbell path (start_cpsch() -> pm_init() ->
kq_initialize() -> kfd_get_kernel_doorbell()), so holding it across
the sleeping allocations above would create a lock-ordering
inversion with dqm->lock via TTM eviction, and it would also
serialize doorbell setup of unrelated processes behind a
device-wide lock for per-process state.
This issue was discovered by Tencent CodeBuddy Security.
v3 (Felix Kuehling):
- Removed unlocked check in kfd_get_process_doorbell flagged as
problematic by Sashiko Bot. Fall back to the locked check inside
kfd_alloc_process_doorbells
- Added missing mutex_destroy
v4 (Felix Kuehling):
- Removed unlocked checks around other kfd_alloc_process_doorbells calls
Fixes: 16f0013157bf ("drm/amdkfd: Allocate doorbells only when needed")
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Set the sdmax_rlcx_dummy_reg1 MQD field to 1 unconditionally in
update_mqd_sdma() for GFX 12.1. This is needed to enable processing of
the Linear Swap Wait/Signal SDMA packet on GFX 12.1.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add a dedicated SDMA MQD definition for GFX 12.1 and switch the
GFX 12.1 paths (sdma_v7_1 and kfd_mqd_manager_v12_1) to it.
No functional change.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When a debugged process exits, kfd_process_notifier_release_internal()
first removes it from kfd_processes_table and then calls
kfd_dbg_trap_disable(), which drains the process interrupts. The drain
sends a fence through the IH and waits, without a timeout, for
kfd_process_close_interrupt_drain() to wake it up. That wakeup looks
the process up by PASID in kfd_processes_table, which no longer holds
it, so the wakeup is lost and the exiting task sleeps forever. The
fatal signal has already been consumed in do_exit(), so the
interruptible wait cannot be broken either.
The wait happens inside the mmu_notifier release callback, i.e. within
the global mmu_notifier SRCU read-side critical section, so every
synchronize_srcu() on it stalls as well. Any other process releasing
its mm then hangs in D state and the system needs a reboot. This is
seen with rocgdb on MI300X.
Fix this by:
- Waiting on a completion in struct amdgpu_fpriv, looked up by PASID
through amdgpu_pasid_xa, instead of looking the process up in
kfd_processes_table. The DRM file owning the PASID is still
referenced by KFD while it drains, so the drain fence always finds
its waiter. The drain logic moves to amdgpu_ids.c and KFD only
passes the PASID.
- Bounding the wait with a timeout, since the fence can be lost when
the IH ring or the KFD interrupt FIFO overflows, and warning when the
drain does not complete.
- Passing drain_irqs to kfd_dbg_trap_disable() and skipping the drain
when the process itself exits. Its interrupts are no longer delivered
once it is out of kfd_processes_table, and its PASID owner is cleared
before the PASID is freed and later reallocated cyclically.
v2: track drains with a completion in amdgpu_fpriv via amdgpu_pasid_xa
and move the drain logic to amdgpu_ids.c; pass drain_irqs to
kfd_dbg_trap_disable() and skip the drain on process exit instead
of deferring it (Felix)
v3: use AMDGPU_FENCE_JIFFIES_TIMEOUT for the drain timeout; drop
kfd_process_close_interrupt_drain() and call
amdgpu_pasid_drain_irq_done() directly from the interrupt handlers
(Felix)
Fixes: 12fb1ad70d65 ("drm/amdkfd: update process interrupt handling for debug events")
Signed-off-by: Heng Zhou <Heng.Zhou@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
prange->svm_bo stays set after the range drops its reference in
svm_range_vram_node_free(), it is only cleared later by
svm_range_bo_release(). Taking a new reference based on old->svm_bo can
therefore hit a svm_bo with refcount 0 and svm_range_bo_release_async()
pending, leaving the clone with a freed svm_bo.
Use svm_bo_ref_unless_zero() under old->lock to only share the svm_bo if
it is still alive, same as svm_range_validate_svm_bo() does.
A range only holds a svm_bo reference while ttm_res is set, so drop the
reference again if old had already dropped its own. The clone keeps the
svm_bo pointer and stays on svm_bo->range_list, so svm_range_bo_release()
clears the pointer when the svm_bo goes away. The unref must be done
outside old->lock because svm_range_bo_release() takes the lock of every
range on the list, including old.
v3: drop the reference if ttm_res is not set, don't leak it.
v2: use svm_bo_ref_unless_zero instead of checking old->ttm_res, to keep
sharing the svm_bo when the range dropped its own reference (Felix).
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On GC 9.4.3, 9.4.4 and 9.5.0, doorbell writes issued from shaders are
routed to an SDMA engine at 32-byte (4 doorbell index) granularity.
SDMA engine doorbell ranges are 10 indices apart, so the range of every
odd engine starts 2 indices into a 4-index block that begins in the
previous engine's range. A shader ringing the doorbell of a queue on an
odd engine therefore rings the previous engine instead. The intended
queue never sees the doorbell, so its work stalls and the application
hangs.
Align the per-engine doorbell base up to a 4-index boundary on these
ASICs. Each engine only uses 4 of its 10 indices, so the aligned base
plus the queue offset stays within the engine's range. Even engines are
already aligned, so only the doorbell IDs of odd-engine queues change.
Only doorbells rung by the device itself are routed this way. Doorbell
writes from the host, including the kernel's own SDMA rings, are not
affected.
The doorbell ID of an SDMA queue is saved in CRIU checkpoints and
checked again on restore. A checkpoint taken before this change that
contains an SDMA queue on an odd engine will fail to restore with
-EINVAL. This is intentional: the restored process still holds the old
doorbell address, so accepting the stale ID would bring back the same
stall.
Tested on MI300X with a shader-rung SDMA doorbell test: queues on odd
engines hung before this change and complete with it.
v2: use u32 instead of uint32_t for the new locals (checkpatch)
v3: name the routing granularity, use dev->node_id, document the
layout invariants, describe impact
v4: express the granularity in doorbell indices, drop unrelated
cleanups, explain the CRIU restore behavior, add test note
Fixes: 6df442a03d1a ("drm/amdgpu: add new doorbell assignment table for aqua_vanjaram")
Signed-off-by: Saleel Kudchadker <Saleel.Kudchadker@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On the A+A VF, VRAM is accessed through the system memory path, so SVM
range PTEs that point at VRAM need AMDGPU_PTE_SYSTEM set, matching what
the graphics paths already do.
v2:
- Use (sriov_vf || passthrough) and amdgpu_virt_vram_is_spm() for
SVM VRAM PTE_SYSTEM.
v3:
- Rely on amdgpu_virt_vram_is_spm() without redundant VF/passthrough
checks.
Signed-off-by: Zhigang Luo <zhigang.luo@amd.com>
Signed-off-by: Fangsheng Huang <Fangsheng.Huang@amd.com>
Signed-off-by: YuBiao Wang <YuBiao.Wang@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On GFX 12.1 AID A0, extended-scope fine-grained local HBM must be
mapped MTYPE_UC when the device is in DPX, QPX or CPX compute partition
mode. In SPX mode the local MTYPE (MTYPE_NC by default) is kept.
Remote VRAM and system memory already use MTYPE_UC.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: David Yat Sin <david.yatsin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Add a helper to extract the AID revision from adev->rev_id, matching
the existing SOC_V1_0_DIE_REV_XCD(), and use it instead of open-coded
rev_id bit checks for AID A1 in gmc_v12_1 and kfd_svm.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: David Yat Sin <david.yatsin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fix a hardware RTL bug in the TCP XNACK scoreboard reset path on MI300,
where a wave receiving a no-retry FAULT from UTC and subsequently
terminating may leave its scoreboard entry uncleared when reset events
arrive back-to-back.
This can cause a later, unrelated wave using the same scoreboard slot
to incorrectly inherit the XNACK error state, resulting in its VMEM
operations being dropped even though the wave never faulted.
Signed-off-by: Gang Ba <Gang.Ba@amd.com>
Reviewed-by: Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
During a GPU reset, evict_process_queues_cpsch() calls remove_queue_mes()
per queue, which fails with -EIO because the recovery path already holds
the reset domain write lock. The loop aborts on the first queue, leaving
the rest with is_active still set while the reset wipes the MES queue
table.
When the process later exits, process_termination_cpsch() sends
REMOVE_QUEUE for doorbells MES no longer knows about. MES rejects them,
the driver reports it as a timeout and concludes MES is unrecoverable,
so it requests another GPU reset.
Failed to evict queue 2
GPU reset(1) succeeded!
failed to remove queue from MES, doorbell=0x1002
MES might be in unrecoverable state, issue a GPU reset
GPU reset begin!. Source: 3
Mark every queue as reset in kgd2kfd_post_reset(). This clears is_active,
corrects the queue counts and sets is_reset so the queue is skipped later.
Add a verbose argument to set_queue_as_reset() so the full reset path
does not log a message for every queue.
Signed-off-by: YuanShang <YuanShang.Mao@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
CWSR ranges use the always mapped flag and only need a mapping on the
GPU running the queue. However, svm_range_validate_and_map now updates
the mapping on every GPU with the ACCESS attribute, which is all
supported GPUs when XNACK is on. After the range is prefetched to VRAM,
those GPUs may span different XGMI hives, so the page owner mismatches
and is set to NULL. hmm_range_fault then tries to migrate the VRAM
pages back to system memory, but svm_migrate_to_ram skips it because
migrating pages back to system memory is not allowed while the GPU
mapping is being updated, so the CPU page fault is never resolved.
Only map to the ACCESS GPUs if the range is not mapped to any GPU and
is not in VRAM.
Fixes: b96f26104946 ("drm/amdkfd: Unmap svm range from GPU set to no-access")
Signed-off-by: Andrew Martin <andrew.martin@amd.com>
Assisted-by: Claude:claude-opus-5
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Commit e1b73b64271d ("amdkfd: remove DIQ support") removed the
KFD_QUEUE_TYPE_DIQ enumerator from enum kfd_queue_type but left its
description behind in the note block.
Fixes: e1b73b64271d ("amdkfd: remove DIQ support")
Signed-off-by: Lu Yao <yaolu@kylinos.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If MODE.DST_VGPR_MSB != MODE.SRC0_VGPR_MSB upon trap entry then
v1 would be trashed.
Adjust workaround to prefetch random address 0xFFFFFFFFxxxxxxxx.
This address space is unavailable to userspace on gfx12.1, ensuring
no functional side-effects of prefetch.
Also remove unused WAVE_START exception handler.
Fixes: 0e1e0f87af55 ("drm/amdkfd: gfx12.1 add no-op prefetch on trap entry")
Signed-off-by: Jay Cornwall <jay.cornwall@amd.com>
Reviewed-by: Lancelot Six <lancelot.six@amd.com>
Cc: Joseph Greathouse <joseph.greathouse@amd.com>
Cc: Vladimir Indic <vladimir.indic@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
kfd_dev_mapping caches the address_space of the first /dev/kfd opener
so that the GPU reset path can call unmap_mapping_range() to zap all
userspace mappings of doorbell and MMIO ranges. This design has two
bugs that both manifest under SRIOV with multiple containers:
1. Use-after-free / rwsem deadlock. The cached pointer refers to an
inode owned by the first opener's container. When that container
exits and its inode is released, kfd_dev_mapping becomes a dangling
pointer. A subsequent GPU reset dereferences it inside
unmap_mapping_range(), which takes i_mmap_rwsem on the freed inode,
causing a hard hang observable as an uninterruptible rwsem wait.
2. Multi-container gap. Only the first opener's address_space is cached;
VMAs created by later openers live in a different address_space and
are never reached by unmap_mapping_range(). After a GPU reset those
stale mappings keep doorbell and MMIO pages accessible to guest
userspace with no GPU behind them, risking PCIe transaction timeouts
and NMI panics.
Fix both bugs with the same approach used by DRM core (drm_drv.c):
create a private pseudo-filesystem at module init time and allocate one
anonymous inode from it. In kfd_open() redirect every opener's
file->f_mapping to that inode's address_space. The inode is
module-owned, lives exactly as long as the amdgpu module, and collects
VMAs from all openers in one address_space. A single
unmap_mapping_range() call in the reset path then correctly reaches
every container's mappings with no dangling pointer risk.
The hang manifests as an NMI backtrace on the GPU reset workqueue stuck
spinning in rwsem_down_read_slowpath() with a corrupted i_mmap_rwsem:
Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu]
Call Trace:
<TASK>
kvm_wait+0x1f/0x40
__pv_queued_spin_lock_slowpath+0x31d/0x3a0
_raw_spin_lock_irq+0x51/0x80
rwsem_down_read_slowpath+0xb3/0x550
down_read+0x48/0xd0
unmap_mapping_range+0x71/0x140
kfd_dev_unmap_mapping_range+0x5b/0x140 [amdgpu]
amdgpu_amdkfd_clear_kfd_mapping+0xd8/0x190 [amdgpu]
amdgpu_device_gpu_recover+0x232/0x450 [amdgpu]
xgpu_ai_mailbox_flr_work+0xb5/0xc0 [amdgpu]
process_one_work+0x18e/0x3e0
worker_thread+0x2e3/0x420
kthread+0x10a/0x230
Fixes: 70cadefcc616 ("drm/amdgpu: unmap all user mappings of framebuffer and doorbell before mode1 reset")
Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The previous change set CP_HQD_PQ_CONTROL.SCOPE=3 (SYSTEM) only for KFD
AQL queues, but PM4 queues and the kernel-managed compute (KCQ) queues
can also use non-coherently cached ring buffers and hit the same
stale-packet problem.
Set the scope for both PM4 queues and KCQs as well.
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
A subset of supported devices can have a mismatch between the logical and
device engine instance numbers which the driver currently solves by a
combination of lookup table generated at driver init time, and a
conditionally set vfunc checked and used at runtime to do the lookup.
As the requirement to do these lookups is relatively widespread in the
code base, plus the fact the mapping table is already allocated for all
possible hw ips and instances, we can significantly streamline them by
initializing the said lookup table unconditionally to the predominant
"identity map" (logical instance numbers equal to device instances),
and allow affected parts to re-configure the table based on their
configuration.
The effect is that for each lookup site we replace the conditional
followed by a indirect function call with a simple two-dimensional table
lookup.
Bloat-o-meter agrees the savings are significant:
add/remove: 13/12 grow/shrink: 23/279 up/down: 51626/-198973 (-147347)
...
Total: Before=10139692, After=9992345, chg -1.45%
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The compute partition switch locked the kfd device, freed it during the
pre-switch teardown, and then unlocked at the end - by which point
adev->kfd.dev referenced the newly reinitialized device, so the unlock
landed on the wrong object and the per-device lock was never balanced.
Add a dedicated prepare function to unwind and clean up kfd device.
Don't use the global lock during teardown. A new device is created after
partition switch; hence there is no need to do 'unlock' on a different
object after the switch.
User is not supposed to run any process on the device during partition
switch. Keep acquire/release semantics for init_complete so that the
device remains unavailable for a process till its reinitialization is
complete.
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fix a hardware RTL bug in the TCP XNACK scoreboard reset path where a wave
receiving a no-retry FAULT from UTC and subsequently terminating may leave
its scoreboard entry uncleared when reset events arrive back-to-back.
This can cause a later, unrelated wave using the same slot to incorrectly
inherit the XNACK error state, resulting in its VMEM operations being
dropped even though the wave never faulted.
Signed-off-by: Gang Ba <Gang.Ba@amd.com>
Reviewed-by: Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The low 6 bits of cp_hqd_eop_control store the base-2 logarithm
of the EOP ring size. This was calculated as
order_base_2(q->eop_ring_buffer_size / 4) - 1
But order_base_2 can in theory return 0, so this could underflow
(although in practice the ring buffer size cannot be less than 4096).
Change this to
order_base_2(q->eop_ring_buffer_size / 8)
using properties of logarithms.
Also add to the above comment to make the mathematics more clear.
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The low 6 bits of cp_hqd_eop_control store the base-2 logarithm
of the EOP ring size. This was calculated as
ffs(q->eop_ring_buffer_size / sizeof(unsigned int)) - 1 - 1
But ffs can in theory return 1 or 0, so this could underflow
(although in practice the ring buffer size cannot be less than 4096).
Change this to
ffs(q->eop_ring_buffer_size / sizeof(unsigned int) / 4)
using properties of logarithms.
Reviewed-by: Kent Russell <kent.russell@amd.com>
Signed-off-by: David Francis <David.Francis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
There is an include loop between amdgpu.h and amdgpu_sdma.h which
prevents adding any interesting static inline helpers to the latter.
Break it by moving the type definitions to a new amdgpu_sdma_types.h
header.
This is required so static inline helpers which need to dereference
struct amdgpu_device can be added to amdgpu_sdma.h.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On GFX 12.1, ring buffers may be mapped with a non-coherently
cached memory type. In that case the queue fetch can observe stale
packets, since the packet producers (CPU or other GPUs) do not keep the
device-side cache coherent.
Set CP_HQD_PQ_CONTROL.SCOPE=3 (SYSTEM) so the queue fetches use
system scope and pick up the latest packets. Apply this to compute queue
MQDs and to MES-managed queues.
Without this, the queue can consume stale packets for long periods,
causing severe slowdowns and, in the worst case, application hangs.
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Joseph Greathouse <joseph.greathouse@amd.com>
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Remove the caller_handles_kernel_queues argument from
the amdgpu_sdma_reset_engine() function and make it
always handle kernel queues.
Now the SDMA recovery sequence is more consistent
between callers for the KFD as follows.
Before recovery: first the KFD is suspended,
then the SDMA queue contents are backed up.
After recovery: first the SDMA queue contents
are restored, then the KFD is resumed.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
kfd_mqd_manager_v12.c (GFX 12.0) and kfd_mqd_manager_v12_1.c (GFX 12.1)
do not implement restore_mqd callbacks, leaving the function pointers
NULL and causing CRIU restore to return -EOPNOTSUPP on GFX12.
Implement restore_mqd for both compute and SDMA queues in
kfd_mqd_manager_v12.c and kfd_mqd_manager_v12_1.c, modeled after the
GFX 11 implementation with the following improvements:
- update cp_mqd_base_addr_lo/hi to the newly allocated MQD address,
fixing a pre-existing gap shared with v11 where the in-MQD copy
still pointed at the old checkpoint-time address after restore
- memset the full allocation before memcpy for compute queues to avoid
stale data in the GTT sub-allocator tail; SDMA MQDs use sizeof(*m)
since they are packed at mqd_size stride in a shared BO
checkpoint_mqd registration is deferred to a follow-up patch that also
implements get_checkpoint_info, so that checkpoint and restore are
enabled together as a complete and testable unit.
Note: GFX12.1 restore handles XCC0 only. Multi-XCC CRIU restore is
currently unreachable due to a separate validation issue in
kfd_criu_restore_queue(). A pr_warn_once() is emitted if a multi-XCC
device is encountered.
Signed-off-by: Vladimir Marioukhine <Vladimir.Marioukhine@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Disable gfxoff while collecting CU occupancy data.
Reported-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Belanger <david.belanger@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-next
amd-drm-next-7.4-2026-09-10:
amdgpu:
- Freesync fixes
- GPUVM fix
- Debugfs fixes
- HDMI updates
- IPS fix
- GPU reset fix
- RGB quantization fixes
- SMU 13.0.x fixes
- MES updates
- UserQ updates
- UVD fix
- Various bounds checks
- DML fixes
- DCN 6 updates
- NBIO 7.11.5 support
- Audio fixes
- More display KUnit tests
- SMU 15 updates
- RAS updates
- VCN 5.0.2 updates
- JPEG 5.0.2 updates
- DCN 4.2 updates
- PSR fixes
- Misc cleanups
- PSP 15.0.8 updates
- RAS BERT support
- RAS CPER updates
- vblank fixes
- LSDMA updates
- GC 12.1 updates
- MMHUB 4.2 updates
- NBIO 6.3.2 updates
- SMU 15.0.8 updates
- IP discovery updates
- GPU spatial partitioning updates
- HDMI 2.1 freesync support
- HDMI 2.1 ALLM support
- HDMI 2.1 VRR support
- Require jobs for IBs
- Enable FRL for HDMI
- MES oversubscription fixes
- IH 6-7 updates
- GMC 11-12 fault handling updates
- Fixed point cleanup
- Backlight fixes
- GPUVM cleanup
- Devcoredump fixes
- UALoE (UALink over Ethernet) Support
- SDMA userq fixes
- GC 8 fix
amdkfd:
- Various bounds checks
- SVM fixes
- GC 12.1 updates
- MES updates
- Trap handler fixes
- Debugfs fixes
drm:
- Add gem callback for when handle count goes to 0
- Rust fix
UAPI:
- INFO IOCTL fix for 32 bit userspace on 64 bit kernel
- Add syncobj_points to USERQ signal ioctl
Proposed userspace:
* radeonsi NV_timeline_semaphore
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37335
* RADV user queues
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40808
- Add UALink support IOCTLs
Proposed userspace:
https://github.com/ROCm/rocm-systems/blob/35959f8e1260c7cee3e51a740e320be3856ee4ff/projects/rocr-runtime/libhsakmt/src/memory.c#L971
https://github.com/ROCm/rocm-systems/blob/35959f8e1260c7cee3e51a740e320be3856ee4ff/projects/rocr-runtime/libhsakmt/src/memory.c#L1036
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260910213040.826425-1-alexander.deucher@amd.com
|
|
GFX 12.1.0 queues are managed by MES, not by the HWS runlist, so the
127 queue limit does not apply.
The topology advertises 32 CP queues plus 16 SDMA engines with 6 queues
each, so creating every queue needs 128 and the last one fails with
-ENOSPC.
Signed-off-by: Horatio Zhang <hongkun.zhang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
Pull kmalloc_obj conversions from Kees Cook:
"Another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules
in scripts/coccinelle/api/kmalloc_objs.cocci"
* tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
treewide: refresh kmalloc_obj() conversions
drm/amd/display: Fix harmless type mismatch in allocation
|
|
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci
This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.
Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.
Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
|
|
Reading /sys/kernel/debug/kfd/mqds while a process holds an active KFD
queue triggers a NULL pointer dereference because the for loop that
calls mqd_mgr->debugfs_show_mqd() is incorrectly placed outside the
if (pqn->q) block that initializes mqd_mgr.
The queue list can contain entries where pqn->q is NULL (kernel queues
where only pqn->kq is valid). In the original code:
if (pqn->q) {
...
mqd_mgr = q->device->dqm->mqd_mgrs[mqd_type];
size = mqd_mgr->mqd_stride(...);
}
for (xcc = 0; xcc < num_xccs; xcc++) { // WRONG: outside if block
mqd = q->mqd + size * xcc;
r = mqd_mgr->debugfs_show_mqd(m, mqd);
}
When iterating over a queue node where pqn->q is NULL:
1. The if (pqn->q) block is skipped
2. mqd_mgr remains uninitialized (NULL from declaration)
3. The for loop executes anyway
4. mqd_mgr->debugfs_show_mqd(m, mqd) dereferences NULL
The crash manifests as:
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor instruction fetch in kernel mode
RIP: 0010:0x0
Call Trace:
pqm_debugfs_mqds+0x10c/0x1d0 [amdgpu]
kfd_debugfs_mqds_by_process+0x9b/0x110 [amdgpu]
seq_read_iter+0x132/0x4b0
...
Fix by moving the for loop inside the if (pqn->q) block, so mqd_mgr
and related variables are only used when properly initialized.
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5689
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260831130051.2031435-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 8bfe29d5c798940f797aa24135d2734c3ffce9de)
Cc: stable@vger.kernel.org
|
|
MES (Micro Engine Scheduler) does not perform heavy-weight TLB
invalidation after unmapping queues, unlike HWS which does this
automatically. This causes a race condition where in-flight DMA
descriptors can access memory that has been unmapped, leading to page
faults and GPU queue hangs during SVM page migration.
The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest
failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU
compute queue hangs with packets submitted but never consumed.
Add kfd_flush_tlb() calls after MES queue removal in two locations:
- evict_process_queues_cpsch(): after all queues removed during eviction
- suspend_queues(): after debug/criu queue suspension (with mem_fence barrier)
This ensures all in-flight memory accesses from unmapped queues are
flushed before memory is freed or migrated.
Signed-off-by: Priya Hosur <Priya.Hosur@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77)
Cc: stable@vger.kernel.org
|
|
Add an amdgpu_mtype_remote module parameter so the MTYPE used for remote
memory accesses can be overridden. For now only MTYPE_NC and MTYPE_UC
are selectable (0 = MTYPE_NC, 1 = MTYPE_UC); it defaults to the
ASIC-dependent value. Currently, it is used only for GFX 12.1.
The MTYPEs resolved for both local and remote memory are logged once.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Name the compute MQD dword at offset 509 (previously reserved_509) as
coherent_aql_mtype in v12_1_compute_mqd and program it when initializing
a compute queue MQD.
The field must be set to 0 whenever the driver maps local or remote
memory as MTYPE_NC, and to 1 in all other cases. Add a shared helper
gmc_v12_1_get_mtypes() as the single source of truth for the local and
remote MTYPE decision (used by both the PTE coherence flags and the MQD
programming), and gmc_v12_1_get_coherent_aql_mtype() which derives the
0/1 value from it.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
On GFX 12.1 remote (non-local / system) memory accesses should always
be mapped as MTYPE_UC.
Signed-off-by: Mukul Joshi <mukul.joshi@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
svm_migrate_vma_to_vram() is called for windows that are already fully
resident in the target GPU's VRAM. migrate_vma_setup() raises an MMU
notifier invalidate before it can discover there is nothing to collect,
and with retry faults enabled svm_range_cpu_invalidate_pagetables()
special cases only MMU_NOTIFY_UNMAP, so MMU_NOTIFY_MIGRATE is handled by
its default arm, reaching svm_range_evict() and then
svm_range_unmap_from_gpus().
The attempt therefore drops the window's GPU mapping and then returns
having migrated nothing, so the next fault on that window is escalated
into another migration instead of being satisfied by mapping alone.
Measured on MI300X (gfx942, SPX/NPS1, xnack+) under an HMM
oversubscription workload, 96 to 97% of to-VRAM migration attempts
collected zero pages, and the driver unmapped a window roughly 35 times
for every migration that moved data.
Test whether every page of the faulting window is already resident in
this node's VRAM and return early if it is. prange->actual_loc alone is
not sufficient: since commit a546a2768440 ("drm/amdkfd: Use partial
migrations/mapping for GPU/CPU page faults in SVM") migration is per
window, so a range can report actual_loc == best_loc while part of it has
been evicted back to system memory. 3.3% of attempts were in exactly that
state and did have pages to move, so the per-page test is required rather
than the scalar alone. Instrumented over 100000 attempts on an earlier
run against a different driver build, the per-page test never skipped one
that had pages to move.
The actual_loc comparison is kept alongside the per-page test because
SVM_RANGE_VRAM_DOMAIN records only that a page is in some device's VRAM,
not which device's.
With this applied the fault driven phase of that workload falls from 270
to 348 s down to 45 to 48 s, across 9 patched and 7 unpatched runs with
no overlap at either oversubscription factor tested. page_in at the end
of that phase does not fall with it: 44.5 to 48.3M pages patched against
44.1 to 49.7M unpatched at factor 1.10, and 46.2 to 48.0M against 44.1 to
45.7M at factor 1.02. Those ranges overlap at 1.10, so the claim is that
no data is stranded, not that more moves. Unmaps per productive migration
fall from about 35 to about 2. Retry fault counts do not fall in any arm,
so this is not a refault loop; what changes is how often a fault
escalates into a migration.
The scan is bounded by the migration window, one granule on the fault
path and the whole range on the prefetch path. That is the same order as
the migrate_vma_setup() walk it avoids, and it returns at the first page
that is not resident, so the worst case is one extra pass over a range
that then migrates normally.
Signed-off-by: William Palacek <William.Palacek@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Reading /sys/kernel/debug/kfd/mqds while a process holds an active KFD
queue triggers a NULL pointer dereference because the for loop that
calls mqd_mgr->debugfs_show_mqd() is incorrectly placed outside the
if (pqn->q) block that initializes mqd_mgr.
The queue list can contain entries where pqn->q is NULL (kernel queues
where only pqn->kq is valid). In the original code:
if (pqn->q) {
...
mqd_mgr = q->device->dqm->mqd_mgrs[mqd_type];
size = mqd_mgr->mqd_stride(...);
}
for (xcc = 0; xcc < num_xccs; xcc++) { // WRONG: outside if block
mqd = q->mqd + size * xcc;
r = mqd_mgr->debugfs_show_mqd(m, mqd);
}
When iterating over a queue node where pqn->q is NULL:
1. The if (pqn->q) block is skipped
2. mqd_mgr remains uninitialized (NULL from declaration)
3. The for loop executes anyway
4. mqd_mgr->debugfs_show_mqd(m, mqd) dereferences NULL
The crash manifests as:
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor instruction fetch in kernel mode
RIP: 0010:0x0
Call Trace:
pqm_debugfs_mqds+0x10c/0x1d0 [amdgpu]
kfd_debugfs_mqds_by_process+0x9b/0x110 [amdgpu]
seq_read_iter+0x132/0x4b0
...
Fix by moving the for loop inside the if (pqn->q) block, so mqd_mgr
and related variables are only used when properly initialized.
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5689
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260831130051.2031435-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
amdgpu_vm_bo_lookup_mapping() expected callers to pre-shift the
address to a page frame number before calling in, unlike its sibling
functions amdgpu_vm_bo_map() and amdgpu_vm_bo_replace_map(), which
accept a raw address and shift internally. This inconsistency meant
every caller had to duplicate the same shift to make it pfn and many
place the shift is not AMDGPU_GPU_PAGE_SHIFT but normal PAGE_SHIFT too.
Move the shift inside amdgpu_vm_bo_lookup_mapping() and update all
callers to stop pre-shifting, so the function's calling convention
matches its siblings.
Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The KFD/userq software oversubscription-notify timers added to
replace GFX11 MES firmware's oversubscription_timer call
amdgpu_mes_notify_unmap_queue(), which takes mes->mutex_hidden,
the same lock add/remove_hw_queue() use. Under SR-IOV this call
can block up to 9s (vs 2.1s bare metal), so MES round-trip latency
goes up (world-switch contention) it stalls re-mapping queues
and times out KFDQMTest.AllCpQueues.
Keep the firmware timer enabled for SR-IOV VFs and skip the
software timers there; the issue this works around is bare-metal
only.
Fixes: 590e26626106 ("drm/amdkfd: workaround 100% gpu usage issue for gfx11")
Signed-off-by: Eric Huang <jinhuieric.huang@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
oversubscription_timer in MES is in micro second, so change the
timer's interval in KFD/useq to micro second.
Signed-off-by: Eric Huang <jinhuieric.huang@amd.com>
Suggested-by: Leo Lin <Leo.Lin@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
MES (Micro Engine Scheduler) does not perform heavy-weight TLB
invalidation after unmapping queues, unlike HWS which does this
automatically. This causes a race condition where in-flight DMA
descriptors can access memory that has been unmapped, leading to page
faults and GPU queue hangs during SVM page migration.
The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest
failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU
compute queue hangs with packets submitted but never consumed.
Add kfd_flush_tlb() calls after MES queue removal in two locations:
- evict_process_queues_cpsch(): after all queues removed during eviction
- suspend_queues(): after debug/criu queue suspension (with mem_fence barrier)
This ensures all in-flight memory accesses from unmapped queues are
flushed before memory is freed or migrated.
Signed-off-by: Priya Hosur <Priya.Hosur@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
VMEM instructions may hang after trap exit. Issue a no-op
prefetch to reset wave VMEM state.
v2: squash in preserve SCC on trap entry
Signed-off-by: Jay Cornwall <jay.cornwall@amd.com>
Cc: Joseph Greathouse <joseph.greathouse@amd.com>
Cc: Michael Chen <michael.chen@amd.com>
Cc: Lancelot Six <lancelot.six@amd.com>
Cc: Vladimir Indic <vladimir.indic@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
on gfx12.1 trap handler
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Jay Cornwall <jay.cornwall@amd.com>
Reviewed-by: Lancelot Six <lancelot.six@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
