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: <Z6RRAXocxWHsZZLF@yilunxu-OptiPlex-7050>
Date: Thu, 6 Feb 2025 14:04:49 +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

> >> 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.

> 
> 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.

Thanks,
Yilun

> there is a match, a specific region driver can handle the enumeration
> within the new region.
> 
> What do you think?
> 
> Thanks,
> Marco
>