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: <20150121202700.GB4942@obsidianresearch.com>
Date:	Wed, 21 Jan 2015 13:27:00 -0700
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	atull <atull@...nsource.altera.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Pavel Machek <pavel@...x.de>, hpa@...or.com,
	Michal Simek <monstr@...str.eu>,
	Michal Simek <michal.simek@...inx.com>,
	Randy Dunlap <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,
	Andrew Morton <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

On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
> Hi Alan,
> 
> > On Jan 21, 2015, at 18:01 , One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:
> > 
> > On Thu, 15 Jan 2015 22:54:46 +0200
> > Pantelis Antoniou <pantelis.antoniou@...sulko.com> wrote:
> > 
> >> Hi Alan,
> >> 
> >>> On Jan 15, 2015, at 22:45 , One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:
> >>> 
> >>> On Thu, 15 Jan 2015 11:47:26 -0700
> >>> Jason Gunthorpe <jgunthorpe@...idianresearch.com> wrote:
> >>>> It is a novel idea, my concern would be that embedding the FPGA in the
> >>>> DT makes it permanent unswappable kernel memory.
> >>>> Not having the kernel hold the FPGA is best for many uses.
> >>> 
> >>> If you have a filesysytem before the FPGA is set up then it belongs in
> >>> the file system. As you presumably loaded the kernel from somewhere there
> >>> ought to be a file system (even an initrd).
> >>> 
> >> 
> >> Request firmware does not imply keeping it around. You can always re-request
> >> when reloading (although there’s a nasty big of caching that needs to be
> >> resolved with the firmware loader).
> > 
> > Which comes down to the same thing. Unless you can prove that there is a
> > path to recover the firmware file that does not have any dependancies
> > upon the firmware executing (and those can be subtle and horrid at times)
> > you need to keep it around for suspend/resume at least and potentially
> > any unexpected error/reset.
> > 
> 
> In that case the only safe place to put it is in the kernel image itself, which
> is something the firmware loader already supports.

My point is that the current firmware layer is overly cautious and
FPGAs are very big. My current project on small Xilinx device has a
10MB programming file. The biggest Xilinx device today has a max
bitfile size around 122MB.

So keeping that much memory pinned in the kernel when I can prove it
is uncessary for my system (either because there is no suspend/resume
possibility, or because I know the CPU can always access the
filesytem) is very undesirable.

Other systems might have to take the ram hit.

Since it seems like the kernel has no way to know, we probably have
have a way to tell it not to cache the bitfile.

Jason
--
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/