linux-kernel - Re: [PATCH V1] accel/amdxdna: Add ioctl DRM_IOCTL_AMDXDNA_GET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <492b465b-03d5-e80e-a31a-79ce4b1f83f7@amd.com>
Date: Wed, 27 Aug 2025 09:41:27 -0700
From: Lizhi Hou <lizhi.hou@....com>
To: Mario Limonciello <mario.limonciello@....com>, <ogabbay@...nel.org>,
	<quic_jhugo@...cinc.com>, <jacek.lawrynowicz@...ux.intel.com>,
	<dri-devel@...ts.freedesktop.org>
CC: <linux-kernel@...r.kernel.org>, <max.zhen@....com>, <sonal.santan@....com>
Subject: Re: [PATCH V1] accel/amdxdna: Add ioctl DRM_IOCTL_AMDXDNA_GET_ARRAY


On 8/26/25 17:31, Mario Limonciello wrote:
> On 8/26/2025 1:10 PM, Lizhi Hou wrote:
>>
>> On 8/26/25 10:58, Mario Limonciello wrote:
>>> On 8/26/2025 12:55 PM, Lizhi Hou wrote:
>>>>
>>>> On 8/26/25 10:18, Mario Limonciello wrote:
>>>>> On 8/25/2025 11:48 PM, Lizhi Hou wrote:
>>>>>>
>>>>>> On 8/25/25 14:28, Mario Limonciello wrote:
>>>>>>> On 8/22/2025 12:23 PM, Lizhi Hou wrote:
>>>>>>>> Add interface for applications to get information array. The 
>>>>>>>> application
>>>>>>>> provides a buffer pointer along with information type, maximum 
>>>>>>>> number of
>>>>>>>> entries and maximum size of each entry. The buffer may also 
>>>>>>>> contain match
>>>>>>>> conditions based on the information type. After the ioctl 
>>>>>>>> completes, the
>>>>>>>> actual number of entries and entry size are returned.
>>>>>>>>
>>>>>>>> Signed-off-by: Lizhi Hou <lizhi.hou@....com>
>>>>>>>
>>>>>>> How does userspace discover whether or not the new IOCTL call is 
>>>>>>> supported?  Just a test call?
>>>>>> The kernel header version will be used to determine whether the 
>>>>>> application which uses new IOCTL will be compiled or not.
>>>>>>
>>>>>
>>>>> But it's not actually an application compile time decision, it's a 
>>>>> runtime decision.  IE I can compile an application with the 
>>>>> headers on kernel 6.18 that has this, but if I try to run it on 
>>>>> 6.15 it's going to barf.
>>>>>
>>>>> To some extent that comes with the territory, but I'm wondering if 
>>>>> a better solution going forward would be for there to be a 
>>>>> dedicated version command that you bump.
>>>>
>>>> For in-tree driver, I did not aware a common way for this other 
>>>> than checking the kernel version.
>>>>
>>>> And here is qaic patch of adding a new IOCTL.
>>>>
>>>> https://github.com/torvalds/linux/ 
>>>> commit/217b812364d360e1933d8485f063400e5dda7d66
>>>>
>>>>
>>>> I know there is major, minor, patchlevel in struct drm_driver. And 
>>>> I think that is not required for in-tree driver.
>>>>
>>>> Please let me know if I missed anything.
>>>>
>>>> Thanks,
>>>
>>> Right; so bump up one of those so that userspace can check it. Maybe 
>>> "minor"?
>>
>> I meant for in-tree driver, is it good enough for userspace to just 
>> check kernel version?  E.g. The drm driver versions are not used by 
>> ivpu or qaic.
>>
>
> Just because they don't doesn't mean you shouldn't.
Ok. :) It does not sound amdxdna specific. Just wondering how the other 
driver/application under accel subsystem handle this.
>
> Take a look at what amdgpu does for user queues earlier this year for 
> example: 100b6010d7540e
>
> This means that a userspace application can look for that minor bump 
> or newer to know the ioctl supports user queues.

As in-tree driver is part of kernel, the userspace application can check 
kernel version to determine whether a feature is supported or not. Could 
you share the idea why would user application to check drm driver 
version for this?

And amdxdna driver is new added driver which never bumped drm 
major/minor before. Thus there is not any application use drm versions. 
Maybe using kernel version directly is good enough in this case?

I am fine to bump minor if it provides better support to user applications.


Thanks,

Lizhi