linux-kernel - Re: [PATCH 2/2] fpga: stratix10-soc: Add persistent SMMU-aware DMA handling for Agilex5

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

Message-ID: <aUVqrU1D+UpfqDlL@yilunxu-OptiPlex-7050>
Date: Fri, 19 Dec 2025 23:09:33 +0800
From: Xu Yilun <yilun.xu@...ux.intel.com>
To: adrianhoyin.ng@...era.com
Cc: dinguyen@...nel.org, mdf@...nel.org, yilun.xu@...el.com,
	trix@...hat.com, linux-fpga@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] fpga: stratix10-soc: Add persistent SMMU-aware DMA
 handling for Agilex5

On Wed, Dec 17, 2025 at 01:56:32PM +0800, adrianhoyin.ng@...era.com wrote:
> From: Adrian Ng Ho Yin <adrianhoyin.ng@...era.com>
> 
> Agilex5 platforms require SMMU translation for FPGA configuration
> buffers, but the Stratix10 FPGA manager previously assumed direct
> physical addressing, causing reconfiguration failures when SMMU was
> enabled.
> 
> This patch adds SMMU-aware DMA mapping and unmapping of service-layer
> buffers and introduces a dma_addr field to track mapped addresses.
> Buffers are also allocated once at probe() instead of per transfer,
> reducing IOMMU overhead and avoiding timeout issues on Agilex5.

The original code allocates the buffer at fpga_manager_ops.write_init(),
a.k.a before re-programming start, not on every write transfer. I don't
understand why there is timeout issue in this phase. I.e. I'm not
convinced the move of buffer allocation brings benefit.

[...]

> @@ -259,6 +256,10 @@ static int s10_send_buf(struct fpga_manager *mgr, const char *buf, size_t count)
>  
>  	svc_buf = priv->svc_bufs[i].buf;
>  	memcpy(svc_buf, buf, xfer_sz);
> +	if (priv->is_smmu_enabled)
> +		priv->svc_bufs[i].dma_addr = dma_map_single(dev, svc_buf,
> +							    SVC_BUF_SIZE,
> +							    DMA_TO_DEVICE);

I'm even more confused now, why the dma mapping here? In patch #1 you've
already mapped the buffer when allocating, you mapped it a second time
here. Moreover the mapped dma_addr is not used anywhere, why?

Thanks,
Yilun