linux-kernel - Re: [RFC v2 1/1] fpga-region: Add generic IOCTL interface for runtime FPGA programming

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: <Z9e8WGzwcDOrx00l@yilunxu-OptiPlex-7050>
Date: Mon, 17 Mar 2025 14:08:24 +0800
From: Xu Yilun <yilun.xu@...ux.intel.com>
To: Marco Pagani <marco.pagani@...ux.dev>
Cc: Nava kishore Manne <nava.kishore.manne@....com>, git@....com,
	mdf@...nel.org, hao.wu@...el.com, yilun.xu@...el.com,
	trix@...hat.com, robh@...nel.org, saravanak@...gle.com,
	linux-kernel@...r.kernel.org, linux-fpga@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [RFC v2 1/1] fpga-region: Add generic IOCTL interface for
 runtime FPGA programming

On Sun, Mar 16, 2025 at 10:55:07PM +0100, Marco Pagani wrote:
> 
> On 2025-03-01 10:27, Xu Yilun wrote:
> > On Mon, Feb 17, 2025 at 04:18:36PM +0100, Marco Pagani wrote:
> >>
> >>
> >> On 06/02/25 07:04, Xu Yilun wrote:
> >>>>>> I'm currently working on an RFC to propose a rework of the fpga
> >>>>>> subsystem in order to make it more aligned with the device model. One of
> >>>>>> the ideas I'm experimenting with is having a bus (struct bus_type) for
> >>>>>> fpga regions (devices) so that we can have region drivers that could
> >>>>>> handle internal device enumeration/management whenever a new region is
> >>>>>> configured on the fabric. Does this make sense in your opinions?
> >>>>>
> >>>>> mm.. I didn't fully understand the need to have a region driver, what's
> >>>>> the issue to solve?
> >>>>>
> >>>>
> >>>> Sorry for the late reply. The general idea is to handle regions in a way
> >>>> that is more aligned with the device model without having to resort to
> >>>> extra ops and additional devices.
> >>>>
> >>>> Having an fpga bus would allow us to handle enumeration using proper
> >>>> region drivers (in the device model sense of the term, i.e., struct
> >>>> device_driver) instead of derived region devices.
> >>>>
> >>>> On second thought, I think having a reconfiguration interface at the
> >>>> fpga manager level is sounder than having it at the region level (one
> >>>> for each region).
> >>>
> >>> I don't think so. A firmware image may contain enumeration info, e.g.
> >>> of-fpga-region. And I think the fpga-region should parse these
> >>> enumeration info rather than fpga manager. fpga manager should only deal
> >>> with content writing stuff and not be exposed to user.
> >>
> >> I agree with that. In my proposal, the fpga manager should be
> >> responsible only for writing the image into the configuration memory
> >> and allocating region devices. In-region enumeration should be handled by
> >> the region drivers.
> >>
> >> My worry with having one reconfiguration interface for each region is
> >> that it does not reflect how the hardware works. To my knowledge, all
> >> major FPGA implementations use a DMA engine (controlled by the fpga
> >> manager) that performs the reconfiguration through a single port. So,
> >> having one interface per region might be conceptually confusing and give
> >> the impression that it is possible to configure regions independently in
> >> parallel.
> > 
> > One interface per region means the regions could be independently
> > reprogrammed, i.e. reprogramming of one region won't affect the working
> > of another region. But they don't have to be reprogrammed in parallel.
> > If it cannot be reprogrammed now, the interface call could fail.
> 
> Good point. However, I still have some other practical concerns. To the
> best of my knowledge, reconfigurable images/bitstreams are statically
> built for a specific reconfigurable region in current FPGA
> implementations. So, what should happen if the user feeds the wrong
> image (e.g., an image targeting another region) into a reconfigurable
> region programming interface? I don't think the fpga manager could and
> should detect these mistakes since the kernel has no visibility of the

I think fpga manager could do something with the helper of HW and image
builder. If the region identifier could be read out from some HW
registers on fpga_region enumeration, and it is also built into the
image header, the fpga manager could check the validity.

Some reprograming engine even enforce the validation by requiring SW
input region identifier along with the image data.

Without the help of HW, I cannot see any SW solution could help, one
interface per region or one interface per engine.

Thanks,
Yilun