linux-kernel - Re: [PATCH v8 2/4] fpga manager: add sysfs interface document

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

Message-Id: <9BA687C8-8C37-48DA-9A76-E82AF2339FF7@konsulko.com>
Date:	Wed, 14 Jan 2015 21:01:33 +0200
From:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	atull <atull@...nsource.altera.com>,
	Pavel Machek <pavel@...x.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, hpa@...or.com,
	Michal Simek <monstr@...str.eu>,
	Michal Simek <michal.simek@...inx.com>, rdunlap@...radead.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	devicetree@...r.kernel.org, robh+dt@...nel.org,
	Grant Likely <grant.likely@...aro.org>, iws@...o.caltech.edu,
	linux-doc@...r.kernel.org, Mark Brown <broonie@...nel.org>,
	philip@...ister.org, rubini@...dd.com,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>,
	jason@...edaemon.net, kyle.teske@...com, nico@...aro.org,
	Felipe Balbi <balbi@...com>, m.chehab@...sung.com,
	davidb@...eaurora.org, Rob Landley <rob@...dley.net>,
	davem@...emloft.net, cesarb@...arb.net, sameo@...ux.intel.com,
	akpm@...ux-foundation.org,
	Linus Walleij <linus.walleij@...aro.org>, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, devel@...verdev.osuosl.org,
	Alan Tull <delicious.quinoa@...il.com>,
	dinguyen@...nsource.altera.com, yvanderv@...nsource.altera.com
Subject: Re: [PATCH v8 2/4] fpga manager: add sysfs interface document

Hi Jason,

> On Jan 14, 2015, at 20:12 , Jason Gunthorpe <jgunthorpe@...idianresearch.com> wrote:
> 
> On Wed, Jan 14, 2015 at 04:06:17PM +0000, One Thousand Gnomes wrote:
> 
>> and I think you effectively have the user usage covered here for such
>> things. It much like GPIO pins - we can describe them but we can also
>> declare they are not visible to the user.
> 
> A missing element in mainline is a kind of VFIO scheme to let user
> space access the FPGA registers designated for user space use.
> 
> We have been using these patches since 2.6.16 to allow user space to
> access the FPGA register resources via a PCI like /sys/../resource0
> mmapable:
> 
>    https://github.com/jgunthorpe/linux/commit/59d5d13ddeffa8980ccc6248ebb5f1678ccb23f4
>    https://github.com/jgunthorpe/linux/commit/7c29c4344627be8a3906d64d32db533bc131df86
>    https://github.com/jgunthorpe/linux/commit/e41bb4a197368a9d505d66b627aee82f2d2b8895
> 
> We deliberately split up the FPGA registers and the assign user space
> permissions to the resource0 files in a way that makes sense for our
> app. Typically there are 10-20 FPGA register regions. User space does
> not access register regions that control DMA.
> 

Interesting.

>> The swappable case mostly comes out of the /dev node. Once you have the
>> dev node it becomes a detail of the OS not the FPGA driver as to who may
>> open it, and how it is handed about. It might be an FPU manager daemon it
>> might not.
> 
> Right, but the thing that scares me about the swappable case is the
> kernel side support.. The FPGA has to connect to the CPU in some way,
> it must have some address assigned, etc. Swapping needs to take care
> of all those details in some way.
> 
> A fixed bus interface block and dynamic reconfiguration for the
> remainder is probably the way to manage that. But, that implies that
> even a family of swappable FPGAs will have a DT overlay associated
> with it.
> 
> Ideally, I could see wanting to have a file format that combines the
> overlay and FPGA bitfile. A loader tool would use the /dev/ interface
> to setup both elements. That would be much more robust than the
> current scheme I see (eg Xilinx) using where the bitfile and DT bit
> live in completely different places and have to be perfectly matched.
> 

A single DT property can be 4 gigs of binary data (cheating a bit, the whole blob can be
4 gigs). You can conceivably include the whole bitfile in the DT blob.

Whether this is a perversion or not it’s left to the reader. The bitfile does
describe the hardware though.

> Jason

Regards

— Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/