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

Message-ID: <Z8LS93jh4KBvNlCd@yilunxu-OptiPlex-7050>
Date: Sat, 1 Mar 2025 17:27:19 +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 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.

> 
> >> With that in place, the fpga manager could request a firmware image,
> >> parse it, write the content into the fpga configuration memory, and then
> >> instantiate the region devices and add them to its fpga bus. Then, if
> > 
> > I think an fpga-region is always there no matter it is cleared, being
> > reprogrammed, or working. So I don't think an fpga-region needs to be
> > re-instantated. The sub devices inside fpga-region needs
> > re-instantating. That's also why I'm hesitating to fpga bus.
> 
> I think one of the issues with the current subsystem architecture is
> that it coalesces two cases: full and partial images. With partial
> images, it makes sense to keep the region devices and rerun the internal
> enumeration. With full images, I believe it makes sense to clear and
> reallocate new devices to set a new region tree.

MM.. I don't actually understand what's the fundamental differences
between full & partial. If a full region supports full & partial
reconfiguration, the full region contains partial regions as
sub-devices. The partial reconfiguration reallocates it sub-devices and
won't change partial region itself. The full reconfiguration also
reallocates it sub-devices including partial regions, and won't change
full region itself.

Thanks,
Yilun