From: "Christian König" <christian.koenig@amd.com>
To: "Kuehling, Felix" <felix.kuehling@amd.com>,
Honglei Huang <honglei1.huang@amd.com>,
Alexander.Deucher@amd.com, Oak.Zeng@amd.com,
Jenny-Jing.Liu@amd.com, Philip.Yang@amd.com,
Xiaogang.Chen@amd.com, Ray.Huang@amd.com, Lingshan.Zhu@amd.com,
Junhua.Shen@amd.com, matthew.brost@intel.com,
rodrigo.vivi@intel.com, thomas.hellstrom@linux.intel.com,
dakr@kernel.org, aliceryhl@google.com
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
honghuan@amd.com
Subject: Re: [RFC/POC PATCH 01/12] drm/amdgpu: add SVM UAPI definitions
Date: Tue, 21 Apr 2026 08:39:02 +0200 [thread overview]
Message-ID: <bf8f0174-c986-4b11-8c83-4be88794c45d@amd.com> (raw)
In-Reply-To: <50d4c92f-cffb-4486-86a9-9e457b879632@amd.com>
On 4/21/26 05:37, Kuehling, Felix wrote:
>
> On 2026-04-20 08:15, Christian König wrote:
>>
>> On 4/20/26 14:07, Honglei Huang wrote:
>>> From: Honglei Huang <honghuan@amd.com>
>>>
>>> Add amdgpu drm SVM API definitions built on the
>>> DRM GPUSVM framework.
>>>
>>> This includes:
>>> - DRM_AMDGPU_GEM_SVM ioctl
>>> - AMDGPU_SVM_FLAG_* flags
>>> - AMDGPU_SVM_OP_SET_ATTR / AMDGPU_SVM_OP_GET_ATTR operations
>>> - AMDGPU_SVM_ATTR_* attribute types
>>> - AMDGPU_SVM_LOCATION_SYSMEM / AMDGPU_SVM_LOCATION_UNDEFINED
>>> - struct drm_amdgpu_svm_attribute and struct drm_amdgpu_gem_svm
>>>
>>> Signed-off-by: Honglei Huang <honghuan@amd.com>
>>> ---
>>> include/uapi/drm/amdgpu_drm.h | 39 +++++++++++++++++++++++++++++++++++
>>> 1 file changed, 39 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
>>> index 406a42be4..bed71ed9b 100644
>>> --- a/include/uapi/drm/amdgpu_drm.h
>>> +++ b/include/uapi/drm/amdgpu_drm.h
>>> @@ -58,6 +58,7 @@ extern "C" {
>>> #define DRM_AMDGPU_USERQ_SIGNAL 0x17
>>> #define DRM_AMDGPU_USERQ_WAIT 0x18
>>> #define DRM_AMDGPU_GEM_LIST_HANDLES 0x19
>>> +#define DRM_AMDGPU_GEM_SVM 0x1a
>>> #define DRM_IOCTL_AMDGPU_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
>>> #define DRM_IOCTL_AMDGPU_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
>>> @@ -79,6 +80,7 @@ extern "C" {
>>> #define DRM_IOCTL_AMDGPU_USERQ_SIGNAL DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_USERQ_SIGNAL, struct drm_amdgpu_userq_signal)
>>> #define DRM_IOCTL_AMDGPU_USERQ_WAIT DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_USERQ_WAIT, struct drm_amdgpu_userq_wait)
>>> #define DRM_IOCTL_AMDGPU_GEM_LIST_HANDLES DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_LIST_HANDLES, struct drm_amdgpu_gem_list_handles)
>>> +#define DRM_IOCTL_AMDGPU_GEM_SVM DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_SVM, struct drm_amdgpu_gem_svm)
>>> /**
>>> * DOC: memory domains
>>> @@ -1665,6 +1667,43 @@ struct drm_color_ctm_3x4 {
>>> __u64 matrix[12];
>>> };
>>> +#define AMDGPU_SVM_FLAG_HOST_ACCESS 0x00000001
>>> +#define AMDGPU_SVM_FLAG_COHERENT 0x00000002
>>> +#define AMDGPU_SVM_FLAG_HIVE_LOCAL 0x00000004
>>> +#define AMDGPU_SVM_FLAG_GPU_RO 0x00000008
>>> +#define AMDGPU_SVM_FLAG_GPU_EXEC 0x00000010
>>> +#define AMDGPU_SVM_FLAG_GPU_READ_MOSTLY 0x00000020
>>> +#define AMDGPU_SVM_FLAG_GPU_ALWAYS_MAPPED 0x00000040
>>> +#define AMDGPU_SVM_FLAG_EXT_COHERENT 0x00000080
>>> +
>>> +#define AMDGPU_SVM_OP_SET_ATTR 0
>>> +#define AMDGPU_SVM_OP_GET_ATTR 1
>>> +
>>> +#define AMDGPU_SVM_ATTR_PREFERRED_LOC 0
>>> +#define AMDGPU_SVM_ATTR_PREFETCH_LOC 1
>> Up till here the interface makes perfect sense, but then it becomes a bit fuzzy.
>>
>>> +#define AMDGPU_SVM_ATTR_ACCESS 2
>>> +#define AMDGPU_SVM_ATTR_ACCESS_IN_PLACE 3
>>> +#define AMDGPU_SVM_ATTR_NO_ACCESS 4
>> Why are those separate attributes? What is the difference between those?
>>
>>> +#define AMDGPU_SVM_ATTR_SET_FLAGS 5
>>> +#define AMDGPU_SVM_ATTR_CLR_FLAGS 6
>> Why is that separated into set and clear flags?
>
> This looks like it's based on the KFD SVM API. We created this so we could set or clear specific flags for address ranges without know what other flags were set or not set on different parts of those address ranges already.
>
> E.g. you may have set an RO flag for pages 1-5, and set a COHERENT flag for pages 3-7. Now you want to clear EXEC for pages 0-8. If you specify an exact flags parameter, you wipe out all those other settings that have different values for different pages in the range. Instead this API lets you say "clear the EXEC flag on pages 0-8 without touching any of the other flags".
>
> Alternatively we could have made all those flags completely separate boolean attributes. Making them flags that can be set/cleared in this way is more economical for how they are stored and manipulated.
Yeah that's exactly what I thought as solution as well.
I mean the kernel can store them internally as flags, but we should clearly have a clean and coherent uAPI for them.
Regards,
Christian.
>
> Regards,
> Felix
>
>
>>
>>> +#define AMDGPU_SVM_ATTR_GRANULARITY 7
>>> +
>>> +#define AMDGPU_SVM_LOCATION_SYSMEM 0
>>> +#define AMDGPU_SVM_LOCATION_UNDEFINED 0xffffffff
>> No location for device local memory?
>>
>>> +
>>> +struct drm_amdgpu_svm_attribute {
>>> + __u32 type;
>>> + __u32 value;
>>> +};
>>> +
>>> +struct drm_amdgpu_gem_svm {
>>> + __u64 start_addr;
>>> + __u64 size;
>>> + __u32 operation;
>>> + __u32 nattr;
>>> + __u64 attrs_ptr;
>>> +};
>> Those struct make perfect sense but clearly need documentation. Preferable as kerneldoc.
>>
>> And we usually use unions in this header to separate the input from the output parameters.
>>
>> Regards,
>> Christian.
>>
>>> +
>>> #if defined(__cplusplus)
>>> }
>>> #endif
next prev parent reply other threads:[~2026-04-21 6:39 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 12:07 [RFC V2 00/12] drm/amdgpu: SVM implementation based on drm_gpusvm Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 01/12] drm/amdgpu: add SVM UAPI definitions Honglei Huang
2026-04-20 12:15 ` Christian König
2026-04-20 13:30 ` Huang, Honglei1
2026-04-20 15:37 ` Christian König
2026-04-20 16:06 ` Matthew Brost
2026-04-20 16:28 ` Thomas Hellström
2026-04-20 18:07 ` Christian König
2026-04-21 5:08 ` Matthew Brost
2026-04-21 6:19 ` Christian König
2026-04-21 6:48 ` Matthew Brost
2026-04-21 7:13 ` Christian König
2026-04-21 9:52 ` Huang, Honglei1
2026-04-23 6:21 ` Huang, Honglei1
2026-04-23 10:39 ` Christian König
2026-04-23 11:06 ` Huang, Honglei1
2026-04-23 20:02 ` Matthew Brost
2026-04-24 10:20 ` Huang, Honglei1
2026-04-24 10:12 ` Huang, Honglei1
2026-04-27 21:05 ` Felix Kuehling
2026-04-28 2:24 ` Huang, Honglei1
2026-04-28 6:49 ` Christian König
2026-04-28 7:00 ` Huang, Honglei1
2026-04-21 3:37 ` Kuehling, Felix
2026-04-21 6:39 ` Christian König [this message]
2026-04-20 12:07 ` [RFC/POC PATCH 02/12] drm/amdgpu: add SVM data structures and header Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 03/12] drm/amdgpu: add SVM attribute data structures Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 04/12] drm/amdgpu: implement SVM attribute tree operations Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 05/12] drm/amdgpu: implement SVM attribute set Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 06/12] drm/amdgpu: add SVM range data structures Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 07/12] drm/amdgpu: implement SVM range PTE flags and GPU mapping Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 08/12] drm/amdgpu: implement SVM range notifier and invalidation Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 09/12] drm/amdgpu: implement SVM range workers Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 10/12] drm/amdgpu: implement SVM core initialization and fini Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 11/12] drm/amdgpu: implement SVM ioctl and fault handler Honglei Huang
2026-04-20 12:07 ` [RFC/POC PATCH 12/12] drm/amdgpu: wire up SVM build system " Honglei Huang
-- strict thread matches above, loose matches on Subject: below --
2026-03-17 11:29 [RFC/POC PATCH 00/12] POC SVM implementation in AMDGPU based on drm_gpusvm Honglei Huang
2026-03-17 11:29 ` [RFC/POC PATCH 01/12] drm/amdgpu: add SVM UAPI definitions Honglei Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bf8f0174-c986-4b11-8c83-4be88794c45d@amd.com \
--to=christian.koenig@amd.com \
--cc=Alexander.Deucher@amd.com \
--cc=Jenny-Jing.Liu@amd.com \
--cc=Junhua.Shen@amd.com \
--cc=Lingshan.Zhu@amd.com \
--cc=Oak.Zeng@amd.com \
--cc=Philip.Yang@amd.com \
--cc=Ray.Huang@amd.com \
--cc=Xiaogang.Chen@amd.com \
--cc=aliceryhl@google.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=felix.kuehling@amd.com \
--cc=honghuan@amd.com \
--cc=honglei1.huang@amd.com \
--cc=matthew.brost@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox