Some older Vega APUs don't provide a very useful string. If we have
a string in amdgpu.ids use that, but fallback to /proc/cpuinfo.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
The string will generally have a CPU and GPU component, so if both
are found split it up. Make sure that it starts with AMD to be
consistent.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
This commit adds essential parameter validation to several key
functions in amdgpu_bo.c to prevent null pointer dereferences
that were causing segmentation faults and improve overall code
robustness.
The changes address the following crash scenario:
Received signal SIGSEGV.
Stack trace:
#0 [fatal_sig_handler+0x17b]
#1 [__sigaction+0x50]
#2 [amdgpu_bo_alloc+0x37]
#3 [__igt_unique____real_main461+0x7d5]
#4 [main+0x2d]
#5 [__libc_init_first+0x90]
#6 [__libc_start_main+0x80]
#7 [_start+0x25]
Changes made:
1. amdgpu_bo_alloc():
- Validate alloc_buffer and buf_handle parameters
- Return -EINVAL if either is NULL
- Prevents null pointer dereference in memset and subsequent operations
2. amdgpu_bo_set_metadata():
- Validate info parameter
- Return -EINVAL if info is NULL
- Prevents accessing invalid metadata structure
3. amdgpu_bo_query_info():
- Validate info parameter in addition to existing bo->handle check
- Return -EINVAL if info is NULL
- Prevents writing to invalid info pointer
4. amdgpu_bo_list_create():
- Validate resources parameter
- Return -EINVAL if resources is NULL when number_of_resources > 0
- Prevents invalid memory access during resource array processing
These changes ensure proper error handling when callers pass invalid
null pointers, preventing potential segmentation faults and making
the API more robust against programming errors. The validation occurs
early in each function to minimize performance impact.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
The correct marketing name is encoded in the model name field
that is read from the hardware on an APU. Try to read from /proc/cpuinfo
when an APU is found to identify such hardware.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
This patch extends the user queue creation API to support:
1. Queue priority levels (normal low, low, normal high, high)
- High priority is restricted to admin-only
2. Secure queue flag for protected content access
The changes include:
- Adding a `flags` parameter to `amdgpu_create_userqueue()`
- Defining priority and security flags in `amdgpu_drm.h`
- Updating the `drm_amdgpu_userq_in` struct to replace padding with flags
- Documenting the new flags field
Related driver patches provided by Alex:
https://lists.freedesktop.org/archives/amd-gfx/2025-April/122782.htmlhttps://lists.freedesktop.org/archives/amd-gfx/2025-April/122780.htmlhttps://lists.freedesktop.org/archives/amd-gfx/2025-April/122786.html
Cc: Koenig, Christian <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse.Zhang <Jesse.zhang@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This patch adds new IOCTL functions to support
userqueue create, remove, signal and wait etc.
v2:(Marek)
- Add csa support for SDMA queue.
- Addressed's review comments.
- Removed raw2/op2 ioctl.
- Added syncobj_timeline_handles in amdgpu_userq_wait IOCTL.
v3:(Yogesh)
- Rename timeline* objects as per UAPI review (Arvind).
v4: (Marek)
- Drop AMDGPU_USERQ_BO_WRITE as this should not be a global option
of the IOCTL, It should be option per buffer. Hence adding separate
array for read and write BO handles. (Arun)
- Modify num_fences to __u16, flags changed to __u16 and placed
the num_fences next to flags for optimal padding and size. (Arun)
v5:(Marek/Pierre-Eric)
- add more detail params description for signal and wait IOCTL calls.
- Remove the unused structure fields in signal and wait structs.
- Add separate array of read and write for BO handles. (Arun)
- Removes the unused flags parameter from the
amdgpu_create_userqueue IOCTL. (Arvind)
v6:(Pierre-Eric)
- Remove unused headers. (Arvind)
- Modify the function parameter names and struct
field names as per the review comments. (Arun)
v7:(Marek)
- Modify the structure field name and comments. (Arun)
- Rename vm_timeline_syncobj and add comment for
vm_timeline_point.
- Remove GDS buffer support from MQD. (Arvind)
v8:(Pierre-Eric)
- Modify the function parameter names.
- Added new function in amdgpu-symbols.txt (Arvind)
v9:(Marek)
- Use the drm signal/wait structure as the parameter. (Arun)
Cc: Deucher, Alexander <alexander.deucher@amd.com>
Cc: Koenig, Christian <christian.koenig@amd.com>
Cc: Sharma, Shashank <shashank.sharma@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Arvind Yadav <arvind.yadav@amd.com>
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
This patch:
- adds a new subquery (AMDGPU_INFO_UQ_FW_AREAS) in AMDGPU_INFO_IOCTL
to get the size and alignment of shadow and csa objects from the
kernel. This information is required for a userqueue consumer (like
MESA/libdrm) to create the userqueue metadata objects properly.
- also adds supporting metadata structures and a high level wrapper
function (amdgpu_query_uq_metadata_info) to the query, to make it
easy to use.
The corresponding kernel changes for this UAPI extension can be found
in amd-gfx mailing list, link:
https://patchwork.freedesktop.org/patch/621390/?series=139715&rev=2
This patch adds support only for the GFX IP, and the other engines may
be supported in subsequent development.
V2: fix the build error due to exporting of helper function
V3: make an entry for amdgpu_query_uq_metadata_info in
amdgpu-symbols.txt
V4: Rename the subquery to AMDGPU_INFO_UQ_FW_AREAS (Marek, Pierre-Eric)
V5: Addressed review comments (Pierre-Eric):
- Fix the API comment to match the new IOCTL name
- remove the unused uq_metadata parameter
Cc: Marek Olsak <marek.olsak@amd.com>
Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: Arvind Yadav <arvind.yadav@amd.com>
Reviewed-by: Marek Olsak <marek.olsak@amd.com>
Signed-off-by: Shashank Sharma <shashank.sharma@amd.com>
There is an excellent writeup explaining this requirement here:
https://gitlab.freedesktop.org/wayland/wayland/-/issues/175
In short, for mixed environments such as the Steam Runtime and other
container-like environments, choosing which libdrm to link into the
client's address space is a hard problem. If the runtime has a newer
libdrm than the host, then it should be preferred, because the client
may be using newly-added symbols. But if the host has a newer libdrm,
then that should be used, because drivers may be depending on those.
Bumping the DSO minor version is transparent to all users because apps
only link against the major version, e.g. DT_NEEDED libdrm.so.2; the
fact that libdrm.so.2 is a link to libdrm.so.2.122.0 is a detail known
only to the loader, but it does let a smart runtime make better
decisions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
See build/soong/README.md for more information about Soong.
Removes BOARD_GPU_DRIVERS, which wasn't affecting anything, since none
of the HAVE_* macros are defined. Even if they were, we'd prefer to
compile all of them so that a single library can support multiple
boards.
The issue was found by a static analysis tool:
Error: LOCK_EVASION (CWE-543):
libdrm-2.4.115/amdgpu/amdgpu_cs.c:596: thread1_checks_field:
Thread1 uses the value read from field "context" in the
condition "sem->signal_fence.context". It sees that the
condition is false. Control is switched to Thread2.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:596: thread2_checks_field:
Thread2 uses the value read from field "context" in the
condition "sem->signal_fence.context". It sees that the
condition is false.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:598: thread2_acquires_lock:
Thread2 acquires lock "amdgpu_context.sequence_mutex".
libdrm-2.4.115/amdgpu/amdgpu_cs.c:599: thread2_modifies_field:
Thread2 sets "context" to a new value. Note that this write can
be reordered at runtime to occur before instructions that do
not access this field within this locked region. After Thread2
leaves the critical section, control is switched back to
Thread1.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:598: thread1_acquires_lock:
Thread1 acquires lock "amdgpu_context.sequence_mutex".
libdrm-2.4.115/amdgpu/amdgpu_cs.c:599: thread1_overwrites_value_in_field:
Thread1 sets "context" to a new value. Now the two threads have
an inconsistent view of "context" and updates to fields of
"context" or fields correlated with "context" may be lost.
libdrm-2.4.115/amdgpu/amdgpu_cs.c:596: use_same_locks_for_read_and_modify:
Guard the modification of "context" and the read used to decide
whether to modify "context" with the same set of locks.
# 597| return -EINVAL;
# 598| pthread_mutex_lock(&ctx->sequence_mutex);
# 599|-> sem->signal_fence.context = ctx;
# 600| sem->signal_fence.ip_type = ip_type;
# 601| sem->signal_fence.ip_instance = ip_instance;
Check `sem->signal_fence.context` in the locked region to avoid a race
condition.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: José Expósito <jexposit@redhat.com>
The devices weren't removed from dev_list.
Instead of just fixing the issue by adding:
if (*node) *node = dev->next;
after the while loop, use this opportunity to use a clearer
control flow.
Fixes: 7275ef8e ("amdgpu: add amdgpu_device_initialize2")
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Allows to opt-out from the device deduplication logic. This is not the
recommended way of using dev handles, but it's necessary for native context:
in this situation one process (eg: Qemu) will init many devices and we
want independent devices to make sure guest applications are isolated from
each other.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is the same functionnality that amdgpu_va_range_alloc offers,
except it's now usable without a device handle.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This will allow applications to use this feature without a device.
The first use case will be native context: we want VA address to
be managed by the guest (to avoid a round-trip to the host to only
generate a VA) but the amdgpu_device only exist on the host.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Until now VA management was tied to a device handle, but there's no
reason for this.
As a first step to export VA management outside of amdgpu_device,
this commit adds a new structure type holding the 4 va_mgr.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Device will be removed from dev_list when refcount reaches 0, so the
dev_mutex must be locked before decreasing reference otherwise there's
a race where this device is still in dev_list with refcount 0 which will
assert or crash in amdgpu_device_initialize trying to use this device
instead of creating new one.
Fixes issue reported in https://gitlab.freedesktop.org/drm/amd/-/issues/2156#note_2268110
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
On 32-bit:
../amdgpu/amdgpu_bo.c: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../amdgpu/amdgpu_bo.c:554:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
cpu < (void*)((uintptr_t)bo->cpu_ptr + bo->alloc_size))
^
Indeed, as amdgpu_bo_info.alloc_size is "uint64_t", the sum is
always 64-bit, while "void *" can be 32-bit or 64-bit.
Fix this by casting bo->alloc_size to "size_t", which is either
32-bit or 64-bit, just like "void *".
Fixes: c6493f360e ("amdgpu: Eliminate void* arithmetic in amdgpu_find_bo_by_cpu_mapping")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
---
v2:
- Add Reviewed-by.
pthread-stubs >= 0.4 simply passes -pthread which is similar to what
dependency('threads') returns. And make it a private dependency
for subprojects even on Linux.
Reviewed-by: Emmanuel Vadot <manu@FreeBSD.org>
The compiler isn't smart enough to tell that this can't happen:
[30/74] Compiling C object amdgpu/libdrm_amdgpu.so.1.0.0.p/amdgpu_bo.c.o
In file included from ../amdgpu/amdgpu_internal.h:32,
from ../amdgpu/amdgpu_bo.c:39:
../xf86atomic.h: In function ‘amdgpu_find_bo_by_cpu_mapping’:
../xf86atomic.h:47:54: warning: ‘bo’ may be used uninitialized [-Wmaybe-uninitialized]
47 | # define atomic_inc(x) ((void) __sync_fetch_and_add (&(x)->atomic, 1))
| ^
../amdgpu/amdgpu_bo.c:536:27: note: ‘bo’ was declared here
536 | struct amdgpu_bo *bo;
| ^~
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Apparently quite a few apps use this API to get the GPU
name and end up with NULL as the GPU name.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This produces no differences in the generated output. I've had to
manually add `requires : 'libdrm'` to libdrm_intel, otherwise libdrm
ends up in `Requires.private` instead of `Requires`.
Signed-off-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
This allows consumers of libdrm as a subproject to use the simpler
`dependency('libdrm', fallback : 'libdrm')` syntax, as the libdrm build
files already tell meson that they override a dependency called
"libdrm".
Signed-off-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Dual purpose:
- The drm fd dedupe functionality confuses the radeonsi
amdgpu winsys if radeonsi isn't the first thing opening
the device. By exposing the fd we can detect this case.
- For a common mesa Vulkan sync objects implementation
with syncobj. (notable: no buffer allocation)
Both shouldn't interferece with libdrm_amdgpu functionality
though it does somewhat piece the abstraction of the library.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3424
Gitlab: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5630
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Instead of using a hand-rolled amdgpu_close_kms_handle function,
use the function from libdrm core, which does exactly the same
thing.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
In Vulkan we have extensions to assist with capture in replay in a
world where addresses are returned to the application. This involves
creating buffers at the same VA during replay as they were during
capture.
By itself libdrm_amdgpu already has support for this, but there is
the obvious failure mode that if another buffer is already allocated
at that VA things fail spectacularly. This is an actual issue as
internal buffers, like winsys images or shader binaries also
participate in the same VA allocation.
To avoid this problem applications have to create buffers which
are going to be captured with a flag, and the implementation is to
separate VA allocation for those buffers to reduce the collision risk:
"Implementations are expected to separate such buffers in the GPU address
space so normal allocations will avoid using these addresses. Apps/tools
should avoid mixing app-provided and implementation-provided addresses for
buffers created with VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT,
to avoid address space allocation conflicts."
This patch implements that by adding a flag for these buffers and allocating
address space from the top of the address range instead of the bottom.
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Christian König <christian.koenig@amd.com>
This allows users to select the library type (static or shared)
using the Meson -Ddefault_library built-in option.
Issue: https://gitlab.freedesktop.org/mesa/drm/-/issues/45
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Fang Tan <tanfang@uniontech.com>
The amdgpu implementation uses `clock_gettime` so it needs to check whether it needs to link
against `-librt`.
Signed-off-by: Valentin Churavy <v.churavy@gmail.com>
Mesa expects to be able to map the same buffer, without unmapping it.
This leads to problem on long-running program.
On the other hand, libdrm uses cpu_map_count as a refcount and expects
its value to decrease so it can unmap buffers.
The previoulsy proprosed fix (https://patchwork.freedesktop.org/patch/258005/)
stopped increased the counter when it went past INT_MAX.
This commit instead proposes to use a larger type to store cpu_map_count.
The outcome is the same: long running apps will not crash, only the
implementation differs.
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1423
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This patch is to use generic variables as the input of amdgpu_cs_submit_raw2.
Because amdgpu_cs_submit_one won't handle IOCTL directly.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
So far, amdgpu_cs_submit_raw2 is mainly used for upper layer (Mesa), however,
amdgpu_cs_submit is used for current all unit tests. Our intention is that the
unit tests can actually verify the API which is really used.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Use alloca instead of malloc, then we don't need free them at the end of this
function.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Combined with -Wundef (added in 75758d2ccf & enforced in ba17673eed),
this provides absolute safety against #ifdef typos.
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
v2: nit-picks fix
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Christian König <Christian.Koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
For the xf86drm.[ch] part : Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
