linux-kernel - Re: [RFC 1/2] fpga: support loading from a pre-allocated buffer

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: <12b50394-3d02-4fe2-9b00-97788b2a64ef@redhat.com>
Date: Mon, 15 Jan 2024 18:08:31 +0100
From: Marco Pagani <marpagan@...hat.com>
To: Nava kishore Manne <nava.kishore.manne@....com>
Cc: mdf@...nel.org, hao.wu@...el.com, yilun.xu@...el.com, trix@...hat.com,
 sumit.semwal@...aro.org, christian.koenig@....com,
 linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org, linaro-mm-sig@...ts.linaro.org,
 dri-devel@...ts.freedesktop.org
Subject: Re: [RFC 1/2] fpga: support loading from a pre-allocated buffer



On 2023-11-22 06:30, Nava kishore Manne wrote:
> Some systems are memory constrained but they need to load very
> large Configuration files. The FPGA subsystem allows drivers to
> request this Configuration image be loaded from the filesystem,
> but this requires that the entire configuration data be loaded
> into kernel memory first before it's provided to the driver.
> This can lead to a situation where we map the configuration
> data twice, once to load the configuration data into kernel
> memory and once to copy the configuration data into the final
> resting place which is nothing but a dma-able continuous buffer.
> 
> This creates needless memory pressure and delays due to multiple
> copies. Let's add a dmabuf handling support to the fpga manager
> framework that allows drivers to load the Configuration data
> directly from a pre-allocated buffer. This skips the intermediate
> step of allocating a buffer in kernel memory to hold the
> Configuration data.

Sharing images/bitstreams using dma-buf to avoid multiple copies
make sense to me to have a fast path for partial reconfiguration.
However, implementing the userspace interface for importing the
buffer at the manager level seems questionable, considering that
the manager should be responsible only for writing images.

Wouldn't it be conceptually cleaner to implement the interface for
importing dma-buf as a separate layer on top of the manager? Such a
layer could then program the FPGA using the standard write_sg 
interface exported by the manager. In this way, each component would
have its own responsibility.

> 
> Signed-off-by: Nava kishore Manne <nava.kishore.manne@....com>
> ---
>  drivers/fpga/fpga-mgr.c       | 113 ++++++++++++++++++++++++++++++++++
>  include/linux/fpga/fpga-mgr.h |  10 +++
>  2 files changed, 123 insertions(+)
> 
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index 06651389c592..23d2b4d45827 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -8,6 +8,8 @@
>   * With code from the mailing list:
>   * Copyright (C) 2013 Xilinx, Inc.
>   */
> +#include <linux/dma-buf.h>
> +#include <linux/dma-map-ops.h>
>  #include <linux/firmware.h>
>  #include <linux/fpga/fpga-mgr.h>
>  #include <linux/idr.h>
> @@ -519,6 +521,39 @@ static int fpga_mgr_buf_load(struct fpga_manager *mgr,
>  	return rc;
>  }
>  
> +static int fpga_dmabuf_load(struct fpga_manager *mgr,
> +			    struct fpga_image_info *info)
> +{
> +	struct dma_buf_attachment *attach;
> +	struct sg_table *sgt;
> +	int ret;
> +
> +	/* create attachment for dmabuf with the user device */
> +	attach = dma_buf_attach(mgr->dmabuf, &mgr->dev);
> +	if (IS_ERR(attach)) {
> +		pr_err("failed to attach dmabuf\n");
> +		ret = PTR_ERR(attach);
> +		goto fail_put;
> +	}
> +
> +	sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> +	if (IS_ERR(sgt)) {
> +		ret = PTR_ERR(sgt);
> +		goto fail_detach;
> +	}
> +
> +	info->sgt = sgt;
> +	ret = fpga_mgr_buf_load_sg(mgr, info, info->sgt);
> +	dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
> +
> +fail_detach:
> +	dma_buf_detach(mgr->dmabuf, attach);
> +fail_put:
> +	dma_buf_put(mgr->dmabuf);
> +
> +	return ret;
> +}
> +
>  /**
>   * fpga_mgr_firmware_load - request firmware and load to fpga
>   * @mgr:	fpga manager
> @@ -573,6 +608,8 @@ int fpga_mgr_load(struct fpga_manager *mgr, struct fpga_image_info *info)
>  {
>  	info->header_size = mgr->mops->initial_header_size;
>  
> +	if (mgr->flags & FPGA_MGR_CONFIG_DMA_BUF)
> +		return fpga_dmabuf_load(mgr, info);

I'm not understanding the whole picture. After the dma-buf has been
imported from userspace, who is supposed to call fpga_mgr_load() or
fpga_region_program_fpga()? And who should load and export the dma-buf
containing the image in the first place?

I think it would be interesting to have a system that buffers a set of
alternative configurations for each (reconfigurable) region. Alternative
configurations could be represented and activated through a sysfs
interface. The user could request a specific configuration by writing in
the corresponding sysfs file, and the system would use the preloaded
image and optionally the overlay to configure the region. What do you
think?

> [...]

Thanks,
Marco