linux-kernel - Re: [RESEND PATCH V7 0/2] AMD QDMA driver

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>] [day] [month] [year] [list]

Message-ID: <1cd7b8ef-a450-974e-cb7a-c4928b726d7d@amd.com>
Date: Wed, 17 Jan 2024 11:58:54 -0800
From: Lizhi Hou <lizhi.hou@....com>
To: Mark Harfouche <mark@...onaoptics.com>
CC: <vkoul@...nel.org>, <dmaengine@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <nishad.saraf@....com>,
	<sonal.santan@....com>, <max.zhen@....com>
Subject: Re: [RESEND PATCH V7 0/2] AMD QDMA driver

Hi Mark,


The QDMA driver has been restructured for upstreaming. And the first 
QDMA patchset supports only AXI4-MM DMA transfers (mentioned in cover 
letter). Directly comparing code with QDMA git repo will not work well.

After QDMA driver patchset is merged, I believe you may submit a fix 
patch to dmaengine for any issue you encounter. We will review your 
patch and verify it with our hardware.


I do not work on the QDMA git repo or forum. I am not the right person 
for questions about QDMA git repo.


Hopefully, this helps.


Thanks,

Lizhi

On 1/14/24 09:54, Mark Harfouche wrote:
> On Wed, Nov 29, 2023 at 12:13 PM Lizhi Hou <lizhi.hou@....com> wrote:
>
>
>     Comparing to AMD/Xilinx XDMA subsystem,
>     https://lore.kernel.org/lkml/Y+XeKt5yPr1nGGaq@matsya/
>     the QDMA subsystem is a queue based, configurable scatter-gather DMA
>     implementation which provides thousands of queues, support for
>     multiple
>     physical/virtual functions with single-root I/O virtualization
>     (SR-IOV),
>     and advanced interrupt support. In this mode the IP provides
>     AXI4-MM and
>     AXI4-Stream user interfaces which may be configured on a per-queue
>     basis.
>     [...]
>     This patch series is to provide the platform driver for AMD QDMA
>     subsystem
>     to support AXI4-MM DMA transfers. More functions, such as AXI4-Stream
>     and SR-IOV, will be supported by future patches.
>
>
> Hello,
>
> My name is Mark Harfouche and I've been following the kernel mailing 
> for some time. I'm sorry if this message is coming months after the 
> initial post. Please let me know if there is a more appropriate venue 
> for this kind of message.
>
> Since 2018 we use QDMA, and continue to build the driver ourselves 
> (with some patches).
> I am really excited to see QDMA mature and become part of the linux 
> kernel.
>
> I wanted to share my experience with the QDMA driver and how I (and 
> other users) feel of how they react to feedback.
>
> Early in its development, the QDMA code base was constantly changing, 
> often breaking the userland code that we were writing to interface 
> with it.
> Beyond this, during our testing, we found it was full of unsafe usage 
> of string operations (for example, sprintf being used in the kernel 
> code without checking the validity of inputs).
> The most breaking changes often included the insertion of variables in 
> enum definitions in the netlink interface (which does not seem 
> included in this original set of patches).
>
> The community of users (beyond just me) has tried in many cases to 
> communicate small compatibility issues between kernel versions, and 
> suggested in many cases fixes in the form of small patches. All of 
> which were met with utter silence. Numerous examples on 
> https://github.com/Xilinx/dma_ip_drivers/pulls
> Some examples of breaking changes to enums (the interface between the 
> kernel code and the userland applications using netlink) can be found 
> between 2020 and today by looking at diffs in the qdma_nl.h (again 
> this file seems absent from the patches) 
> https://github.com/Xilinx/dma_ip_drivers/compare/2020.2...master#diff-4497b037af6c3a4f9ac917e639b58a1fa155feb4b62b7fe66741a42ed74cdfd6
>
> While I understand that in 2018-2022 the driver was not considered 
> stable, I am wondering what kind of mechanism for user feedback will 
> be available now that these patches are being submitted to the linux 
> kernel. Will the community be able to submit patches that resolve the 
> issues we find? Is AMD/Xilinx willing to stand behind their API moving 
> forward?
>
> Thank you for your time,
>
> Mark
>
> PS. I may have posted on various Xilinx/AMD/Github forums. My handle 
> there is often mark_ramona or hmaarrfk