netdev - Re: [PATCH v8 01/27] cxl: add type2 device basic support

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: <5cd8ee3d-c764-403d-9b9b-bca268b33383@amd.com>
Date: Thu, 6 Feb 2025 17:37:31 +0000
From: Alejandro Lucero Palau <alucerop@....com>
To: Dan Williams <dan.j.williams@...el.com>, alejandro.lucero-palau@....com,
 linux-cxl@...r.kernel.org, netdev@...r.kernel.org, martin.habets@...inx.com,
 edward.cree@....com, davem@...emloft.net, kuba@...nel.org,
 pabeni@...hat.com, edumazet@...gle.com, dave.jiang@...el.com
Subject: Re: [PATCH v8 01/27] cxl: add type2 device basic support


On 2/5/25 20:05, Dan Williams wrote:
> Dan Williams wrote:
> [..]
>> I think there is a benefit from a driver being able to do someting like:
>>
>> struct my_cxl_accelerator_context {
>>      ...
>>      struct cxl_dev_state cxlds;
>>      ...
>> };
>>
>> Even if the rule is that direct consumption of 'struct cxl_dev_state'
>> outside of the cxl core is unwanted.
>>
>> C does not make this easy, so it is either make the definition of
>> 'struct cxl_dev_state' public to CXL accelerator drivers so that they
>> know the size, or add an allocation API that takes in the extra size
>> that accelerator needs to allocate the core CXL context.
> Jason has a novel approach to this problem of defining an allocation
> interface that lets the caller register a caller provided data structure
> that wraps a core internal object. Have a look at fwctl_alloc_device()
> for inspiration:
>
> http://lore.kernel.org/1-v3-960f17f90f17+516-fwctl_jgg@nvidia.com


I'm not sure what you mean here, and I just gave a quick look to that 
reference, but in my opinion, it is quite different userspace triggering 
some sort of allocation based on some sysfs files giving the relevant 
information than a kernel driver using an internal kernel API.


Anyway, if you have look at v10, I have modified the accel driver 
allocation for state using the memdev state instead which makes more 
sense to me. I did use that from your original patch, but it makes 
things complicated and a Type2 is a memdev after all. The code is 
cleaner and simpler now.