Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1621580 > unrolled thread

Re: [PATCH 00/16] Intel FPGA Device Drivers

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 00/16] Intel FPGA Device Drivers "Luebbers, Enno" <enno.luebbers@intel.com> - 2017-04-11 21:40 +0200
    Re: [PATCH 00/16] Intel FPGA Device Drivers Jerome Glisse <jglisse@redhat.com> - 2017-04-12 15:30 +0200
      Re: [PATCH 00/16] Intel FPGA Device Drivers Moritz Fischer <moritz.fischer@ettus.com> - 2017-04-12 16:50 +0200
        Re: [PATCH 00/16] Intel FPGA Device Drivers Jerome Glisse <jglisse@redhat.com> - 2017-04-12 17:40 +0200
          Re: [PATCH 00/16] Intel FPGA Device Drivers "Luebbers, Enno" <enno.luebbers@intel.com> - 2017-04-14 21:50 +0200
            Re: [PATCH 00/16] Intel FPGA Device Drivers Jerome Glisse <jglisse@redhat.com> - 2017-04-14 23:00 +0200
              Re: [PATCH 00/16] Intel FPGA Device Drivers Alan Tull <atull@kernel.org> - 2017-04-17 17:40 +0200
                Re: [PATCH 00/16] Intel FPGA Device Drivers Jerome Glisse <jglisse@redhat.com> - 2017-04-17 18:00 +0200
                  Re: [PATCH 00/16] Intel FPGA Device Drivers Alan Tull <atull@kernel.org> - 2017-04-17 18:30 +0200
                    Re: [PATCH 00/16] Intel FPGA Device Drivers Jerome Glisse <jglisse@redhat.com> - 2017-04-17 19:20 +0200
                  Re: [PATCH 00/16] Intel FPGA Device Drivers Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-04-18 16:30 +0200
                    Re: [PATCH 00/16] Intel FPGA Device Drivers Jerome Glisse <jglisse@redhat.com> - 2017-04-18 17:00 +0200

#1621580 — Re: [PATCH 00/16] Intel FPGA Device Drivers

Hi Jerome,

On Thu, Apr 06, 2017 at 04:27:00PM -0400, Jerome Glisse wrote:

> Do we have an open source toolchain to generate the FPGA configuration
> (bitstream) ? As it is required for the GPU sub-system that any driver
> API must comes with open source userspace.

As far as I know, no FPGA vendor currently provides an open-source version of
their FPGA synthesis tools - there are, however, free (as in beer) versions
available for download that can be used for generating FPGA bitstreams. Also,
there are a number of projects to replace parts of the vendor tools with open
alternatives (yosys comes to mind, which I believe recently added initial
support for synthesizing logic for Intel FPGAs).

As an aside, we are also working on an open-source user-space library that would
allow you to use this driver to load existing accelerator bitstreams as well as
enumerate and access accelerators present in the system. This would enable
workflows where users have access to e.g. a library of FPGA accelerator
bitstreams and want to write applications that take advantage of these
accelerators, even without having access to an FPGA synthesis tool.

Thanks
- Enno

[toc] | [next] | [standalone]

#1622136

On Tue, Apr 11, 2017 at 12:38:10PM -0700, Luebbers, Enno wrote:
> Hi Jerome,
> 
> On Thu, Apr 06, 2017 at 04:27:00PM -0400, Jerome Glisse wrote:
> 
> > Do we have an open source toolchain to generate the FPGA configuration
> > (bitstream) ? As it is required for the GPU sub-system that any driver
> > API must comes with open source userspace.
> 
> As far as I know, no FPGA vendor currently provides an open-source version of
> their FPGA synthesis tools - there are, however, free (as in beer) versions
> available for download that can be used for generating FPGA bitstreams. Also,
> there are a number of projects to replace parts of the vendor tools with open
> alternatives (yosys comes to mind, which I believe recently added initial
> support for synthesizing logic for Intel FPGAs).
> 
> As an aside, we are also working on an open-source user-space library that would
> allow you to use this driver to load existing accelerator bitstreams as well as
> enumerate and access accelerators present in the system. This would enable
> workflows where users have access to e.g. a library of FPGA accelerator
> bitstreams and want to write applications that take advantage of these
> accelerators, even without having access to an FPGA synthesis tool.

Yosys is not an open source toolchain is use quartus at least that is my
understand from this commit:

https://github.com/cliffordwolf/yosys/commit/c27dcc1e47fa00cd415893c9d3f637a5d5865988


It is like if on GPU we only had close source compiler for the GPU
instructions set. So FPGA is definitly following different rules than
open source upstream GPU kernel driver abides to.

I see this as highly problematic if not only for security purposes
there is no way for anyone to audit how secure and sane the API you
want to expose to userspace. Those FPGA might have connection to
memory bus or device bus and thus they might get access to any memory.

So i am baffle on how anyone can do any serious review of anything the
fpga driver are doing.

Jérôme

[toc] | [prev] | [next] | [standalone]

#1622204

Hi Jerome,

On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@redhat.com> wrote:
> On Tue, Apr 11, 2017 at 12:38:10PM -0700, Luebbers, Enno wrote:
>> Hi Jerome,
>>
>> On Thu, Apr 06, 2017 at 04:27:00PM -0400, Jerome Glisse wrote:
>>
>> > Do we have an open source toolchain to generate the FPGA configuration
>> > (bitstream) ? As it is required for the GPU sub-system that any driver
>> > API must comes with open source userspace.

I think the comparison lacks. No one seems to be bothered by the fact
that the GPUs
hardware is built using closed source CAD tools, even if open source drivers are
available. From an OS perspective the FPGA is hardware.
(Reconfigurable) but hardware.

A better comparison from my point of view would be loading a binary
firmware image ...

>> As far as I know, no FPGA vendor currently provides an open-source version of
>> their FPGA synthesis tools - there are, however, free (as in beer) versions
>> available for download that can be used for generating FPGA bitstreams. Also,
>> there are a number of projects to replace parts of the vendor tools with open
>> alternatives (yosys comes to mind, which I believe recently added initial
>> support for synthesizing logic for Intel FPGAs).
>>
>> As an aside, we are also working on an open-source user-space library that would
>> allow you to use this driver to load existing accelerator bitstreams as well as
>> enumerate and access accelerators present in the system. This would enable
>> workflows where users have access to e.g. a library of FPGA accelerator
>> bitstreams and want to write applications that take advantage of these
>> accelerators, even without having access to an FPGA synthesis tool.
>
> Yosys is not an open source toolchain is use quartus at least that is my
> understand from this commit:
> https://github.com/cliffordwolf/yosys/commit/c27dcc1e47fa00cd415893c9d3f637a5d5865988
>
>
> It is like if on GPU we only had close source compiler for the GPU
> instructions set. So FPGA is definitly following different rules than
> open source upstream GPU kernel driver abides to.
>
> I see this as highly problematic if not only for security purposes
> there is no way for anyone to audit how secure and sane the API you
> want to expose to userspace. Those FPGA might have connection to
> memory bus or device bus and thus they might get access to any memory.

It's up to the user to plug a specific piece of hardware into their
machine. After that it is
up to the user to decide whether he wants to load a bitstream that he
doesn't have the
source code for and that he needs to compile with closed source software.
Do you know if NVIDIA has backdoors in their GPU, Intel in their NIC,
or AMD in their
processor? What about that RTC, do you have the source code they
synthesized their
ASIC design from?

Maybe my mental model on FPGAs is different from yours so feel free to
disagree ;-)

Moritz

[toc] | [prev] | [next] | [standalone]

#1622252

On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
> Hi Jerome,
> 
> On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@redhat.com> wrote:
> > On Tue, Apr 11, 2017 at 12:38:10PM -0700, Luebbers, Enno wrote:
> >> Hi Jerome,
> >>
> >> On Thu, Apr 06, 2017 at 04:27:00PM -0400, Jerome Glisse wrote:
> >>
> >> > Do we have an open source toolchain to generate the FPGA configuration
> >> > (bitstream) ? As it is required for the GPU sub-system that any driver
> >> > API must comes with open source userspace.
> 
> I think the comparison lacks. No one seems to be bothered by the fact
> that the GPUs hardware is built using closed source CAD tools, even if
> open source drivers are available. From an OS perspective the FPGA is
> hardware. (Reconfigurable) but hardware.
> 
> A better comparison from my point of view would be loading a binary
> firmware image ...

I disagree here, Altera or Xilinx provide OpenCL implementation that allows
to use FPGA. Moreover FPGA are way more capable that micro-controller on
which vast majority of firmware are running.


> >> As far as I know, no FPGA vendor currently provides an open-source version of
> >> their FPGA synthesis tools - there are, however, free (as in beer) versions
> >> available for download that can be used for generating FPGA bitstreams. Also,
> >> there are a number of projects to replace parts of the vendor tools with open
> >> alternatives (yosys comes to mind, which I believe recently added initial
> >> support for synthesizing logic for Intel FPGAs).
> >>
> >> As an aside, we are also working on an open-source user-space library that would
> >> allow you to use this driver to load existing accelerator bitstreams as well as
> >> enumerate and access accelerators present in the system. This would enable
> >> workflows where users have access to e.g. a library of FPGA accelerator
> >> bitstreams and want to write applications that take advantage of these
> >> accelerators, even without having access to an FPGA synthesis tool.
> >
> > Yosys is not an open source toolchain is use quartus at least that is my
> > understand from this commit:
> > https://github.com/cliffordwolf/yosys/commit/c27dcc1e47fa00cd415893c9d3f637a5d5865988
> >
> >
> > It is like if on GPU we only had close source compiler for the GPU
> > instructions set. So FPGA is definitly following different rules than
> > open source upstream GPU kernel driver abides to.
> >
> > I see this as highly problematic if not only for security purposes
> > there is no way for anyone to audit how secure and sane the API you
> > want to expose to userspace. Those FPGA might have connection to
> > memory bus or device bus and thus they might get access to any memory.
> 
> It's up to the user to plug a specific piece of hardware into their
> machine. After that it is up to the user to decide whether he wants
> to load a bitstream that he doesn't have the  source code for and
> that he needs to compile with closed source software. Do you know if
> NVIDIA has backdoors in their GPU, Intel in their NIC, or AMD in their
> processor? What about that RTC, do you have the source code they
> synthesized their ASIC design from?

User do not always know what program their executing. Think someone browsing
some random website, through javascript program you might be able to escape
the web browser and look for fpga device file, if on is present then it
might be able to load a bitstream that would allow it to overwritte system
memory and gain root privilege.

Even if you restrict the ioctl to upload bitstream to root user or some
privilege user, you have to think about VM world. Someone from inside a
vm that has access to an fpga device might be able to upload a bitstream
that would allow to escape the vm and gain root privilege on the host
operating system.

Security expert have proven over and over that no matter how unlikely a
path looks to you, no matter how hard, they will eventualy leverage it.


So you ignoring this issue doesn't make it less real. Pretending that
"secret" bitstream protect you or that only user will load a bitstream
is burying your head in the sand.


So yes knowing the bitstream and links the device has is necessary to be
able to evaluate the security implication of what the kernel fpga driver
are doing.

Cheers,
Jérôme

[toc] | [prev] | [next] | [standalone]

#1623888

On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote:
> On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
> > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@redhat.com> wrote:
> >
> > > It is like if on GPU we only had close source compiler for the GPU
> > > instructions set. So FPGA is definitly following different rules than
> > > open source upstream GPU kernel driver abides to.
> > >
> > > I see this as highly problematic if not only for security purposes
> > > there is no way for anyone to audit how secure and sane the API you
> > > want to expose to userspace. Those FPGA might have connection to
> > > memory bus or device bus and thus they might get access to any memory.
> > 
> > It's up to the user to plug a specific piece of hardware into their
> > machine. After that it is up to the user to decide whether he wants
> > to load a bitstream that he doesn't have the  source code for and
> > that he needs to compile with closed source software. Do you know if
> > NVIDIA has backdoors in their GPU, Intel in their NIC, or AMD in their
> > processor? What about that RTC, do you have the source code they
> > synthesized their ASIC design from?
> 
> User do not always know what program their executing. Think someone browsing
> some random website, through javascript program you might be able to escape
> the web browser and look for fpga device file, if on is present then it
> might be able to load a bitstream that would allow it to overwritte system
> memory and gain root privilege.
> 
> Even if you restrict the ioctl to upload bitstream to root user or some
> privilege user, you have to think about VM world. Someone from inside a
> vm that has access to an fpga device might be able to upload a bitstream
> that would allow to escape the vm and gain root privilege on the host
> operating system.

If you're worried about an accelerator on an FPGA going rogue and accessing
arbitrary host memory, consider that other (non-FPGA) hardware devices could
potentially do that, too (e.g. a PCIe device with a programmable DMA engine).
So this is not really an FPGA-specific concern.

Also, I don't think having an open-source toolchain would help defend against
these kind of attacks at all. Just because you can generate bitstreams with an
open-source tool doesn't prevent the attacker from loading his own bitstreams.
Instead, you'll need to make sure that their bitstream (open-source or not), or,
in fact, any device, is prevented from accessing memory it's not authorized to
access, e.g. with an IOMMU programmed via the kernel's DMA API.

But that's not a toolchain issue.

Thanks
- Enno

[toc] | [prev] | [next] | [standalone]

#1623910

On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote:
> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote:
> > On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
> > > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@redhat.com> wrote:
> > >
> > > > It is like if on GPU we only had close source compiler for the GPU
> > > > instructions set. So FPGA is definitly following different rules than
> > > > open source upstream GPU kernel driver abides to.
> > > >
> > > > I see this as highly problematic if not only for security purposes
> > > > there is no way for anyone to audit how secure and sane the API you
> > > > want to expose to userspace. Those FPGA might have connection to
> > > > memory bus or device bus and thus they might get access to any memory.
> > > 
> > > It's up to the user to plug a specific piece of hardware into their
> > > machine. After that it is up to the user to decide whether he wants
> > > to load a bitstream that he doesn't have the  source code for and
> > > that he needs to compile with closed source software. Do you know if
> > > NVIDIA has backdoors in their GPU, Intel in their NIC, or AMD in their
> > > processor? What about that RTC, do you have the source code they
> > > synthesized their ASIC design from?
> > 
> > User do not always know what program their executing. Think someone browsing
> > some random website, through javascript program you might be able to escape
> > the web browser and look for fpga device file, if on is present then it
> > might be able to load a bitstream that would allow it to overwritte system
> > memory and gain root privilege.
> > 
> > Even if you restrict the ioctl to upload bitstream to root user or some
> > privilege user, you have to think about VM world. Someone from inside a
> > vm that has access to an fpga device might be able to upload a bitstream
> > that would allow to escape the vm and gain root privilege on the host
> > operating system.
> 
> If you're worried about an accelerator on an FPGA going rogue and accessing
> arbitrary host memory, consider that other (non-FPGA) hardware devices could
> potentially do that, too (e.g. a PCIe device with a programmable DMA engine).
> So this is not really an FPGA-specific concern.

Yes but linux kernel driver for those is auditable we can check how such DMA
engine are programmed and in many case userspace do not even have any control
on those (nor indirect nor direct). For the few driver that expose such DMA
engine to userspace we can audit the ioctl and see if they can be abuse to do
rogue DMA.


> Also, I don't think having an open-source toolchain would help defend against
> these kind of attacks at all. Just because you can generate bitstreams with an
> open-source tool doesn't prevent the attacker from loading his own bitstreams.
> Instead, you'll need to make sure that their bitstream (open-source or not), or,
> in fact, any device, is prevented from accessing memory it's not authorized to
> access, e.g. with an IOMMU programmed via the kernel's DMA API.
> 
> But that's not a toolchain issue.

Open source toolchain allows to audit all the in and out of the fpga, to know
how you can connect the fpga logic to the outside world and to know how this
inter-connect interface with the fpga fabrics. Without such knowledge we are
left to believe that the fpga logic can only go through some dedicated block
that itself have to go through IOMMU. So it is security through obscurity.


Note that security is just an example of why open source toolchain matter.
But this is a more fundamental issue in respect to linux kernel rules. Like
i said such thing would be totaly forbidden for the GPU driver and for any
other upstream driver in the linux kernel. It seems that the FPGA folks got
granted an exception that was never granted to anyone else and i would like
to know why.

No driver in kernel without open source userspace have been the rule for all
the other drivers. Just open sourcing some helper that load the bitstream does
not cut it in my view.

Jérôme

[toc] | [prev] | [next] | [standalone]

#1624721

On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse <jglisse@redhat.com> wrote:

Hi Jerome,

> On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote:
>> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote:
>> > On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
>> > > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@redhat.com> wrote:
>> > >
>> > > > It is like if on GPU we only had close source compiler for the GPU
>> > > > instructions set. So FPGA is definitly following different rules than
>> > > > open source upstream GPU kernel driver abides to.

Sorry, not a GPU guy, can you point me to something that documents
this policy of 'only opensource compilers for GPU'?  I looked under
linux/Documentation and didn't see anything.

The current patchset doesn't have anything to do with FPGA toolchains
but you're using this patchset as a platform to talk about toolchain
issues.

It sounds like you are opposed to any kernel support of loading images
on FPGAs until all vendors have opensource toolchains.

Alan

[toc] | [prev] | [next] | [standalone]

#1624728

On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote:
> On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse <jglisse@redhat.com> wrote:
> 
> Hi Jerome,
> 
> > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote:
> >> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote:
> >> > On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
> >> > > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@redhat.com> wrote:
> >> > >
> >> > > > It is like if on GPU we only had close source compiler for the GPU
> >> > > > instructions set. So FPGA is definitly following different rules than
> >> > > > open source upstream GPU kernel driver abides to.
> 
> Sorry, not a GPU guy, can you point me to something that documents
> this policy of 'only opensource compilers for GPU'?  I looked under
> linux/Documentation and didn't see anything.

https://lists.freedesktop.org/archives/dri-devel/2010-July/001828.html

There is no explicit mention about compiler but trust me it is included
in everyones mind. You can ask Dave i am sure he would reject a driver
with everything open except the shader compiler.


> The current patchset doesn't have anything to do with FPGA toolchains
> but you're using this patchset as a platform to talk about toolchain
> issues.

Well Intel inclusion of FPGA triggered my curiosity and when that patchset
came accross my inbox i did wonder where the open source userspace was and
went looking for it to no avail. So this isn't against a specific patchset
but more broadly against the whole drivers/fpga/ story. Sorry if this was
not clear.


> It sounds like you are opposed to any kernel support of loading images
> on FPGAs until all vendors have opensource toolchains.

Yes that is what i am saying. They are different standard in the kernel
and i would rather have one clear standard about driver needing proper
open source userspace to go along with any upstream driver.

Beside when it comes to FPGA i am still puzzle on why no one release info
on the bitstream. They all provide details documentation on the internal
(LUT, flip-flop, logic block layout and connection, memory block, ...).
So there is nothing hidden in the bitstream. I am guessing the only good
reason i can think of is to make it harder to map a bitstream back to
VHDL/Verilog/...

Cheers,
Jérôme

[toc] | [prev] | [next] | [standalone]

#1624735

On Mon, Apr 17, 2017 at 10:57 AM, Jerome Glisse <jglisse@redhat.com> wrote:
> On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote:
>> On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse <jglisse@redhat.com> wrote:
>>
>> Hi Jerome,
>>
>> > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote:
>> >> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote:
>> >> > On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
>> >> > > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@redhat.com> wrote:
>> >> > >
>> >> > > > It is like if on GPU we only had close source compiler for the GPU
>> >> > > > instructions set. So FPGA is definitly following different rules than
>> >> > > > open source upstream GPU kernel driver abides to.
>>
>> Sorry, not a GPU guy, can you point me to something that documents
>> this policy of 'only opensource compilers for GPU'?  I looked under
>> linux/Documentation and didn't see anything.
>
> https://lists.freedesktop.org/archives/dri-devel/2010-July/001828.html

This starts out saying:

"Now this is just my opinion as maintainer of the drm, and doesn't
reflect anyone or any official policy"

> There is no explicit mention about compiler

You are right about that, there is no mention about compiler.

> but trust me it is included
> in everyones mind. You can ask Dave i am sure he would reject a driver
> with everything open except the shader compiler.

How would that work?  Before the GPU driver is accepted, an open
toolchain also needs to be submitted?

It's worth it to check out the responses since they not overwhelmingly
positive and tend to rather be outlining the complicating factors.
Many if not most say essentially that his stance was simplistic and
unproductive, slamming the door on the people from whom the solution
would come.  And keep in mind, this wasn't about what you've made it
out to be in the first place; this is about open/closed source GPU
drivers, not toolchains.

>
>
>> The current patchset doesn't have anything to do with FPGA toolchains
>> but you're using this patchset as a platform to talk about toolchain
>> issues.
>
> Well Intel inclusion of FPGA triggered my curiosity and when that patchset
> came accross my inbox i did wonder where the open source userspace was and
> went looking for it to no avail. So this isn't against a specific patchset
> but more broadly against the whole drivers/fpga/ story. Sorry if this was
> not clear.
>
>
>> It sounds like you are opposed to any kernel support of loading images
>> on FPGAs until all vendors have opensource toolchains.
>
> Yes that is what i am saying. They are different standard in the kernel
> and i would rather have one clear standard about driver needing proper
> open source userspace to go along with any upstream driver.

Deleting drivers/fpga wouldn't be a step forward to the openness you seek.

>
> Beside when it comes to FPGA i am still puzzle on why no one release info
> on the bitstream. They all provide details documentation on the internal
> (LUT, flip-flop, logic block layout and connection, memory block, ...).
> So there is nothing hidden in the bitstream. I am guessing the only good
> reason i can think of is to make it harder to map a bitstream back to
> VHDL/Verilog/...
>
> Cheers,
> Jérôme

[toc] | [prev] | [next] | [standalone]

#1624754

On Mon, Apr 17, 2017 at 11:22:08AM -0500, Alan Tull wrote:
> On Mon, Apr 17, 2017 at 10:57 AM, Jerome Glisse <jglisse@redhat.com> wrote:
> > On Mon, Apr 17, 2017 at 10:35:01AM -0500, Alan Tull wrote:
> >> On Fri, Apr 14, 2017 at 3:49 PM, Jerome Glisse <jglisse@redhat.com> wrote:
> >>
> >> Hi Jerome,
> >>
> >> > On Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote:
> >> >> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote:
> >> >> > On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
> >> >> > > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@redhat.com> wrote:
> >> >> > >
> >> >> > > > It is like if on GPU we only had close source compiler for the GPU
> >> >> > > > instructions set. So FPGA is definitly following different rules than
> >> >> > > > open source upstream GPU kernel driver abides to.
> >>
> >> Sorry, not a GPU guy, can you point me to something that documents
> >> this policy of 'only opensource compilers for GPU'?  I looked under
> >> linux/Documentation and didn't see anything.
> >
> > https://lists.freedesktop.org/archives/dri-devel/2010-July/001828.html
> 
> This starts out saying:
> 
> "Now this is just my opinion as maintainer of the drm, and doesn't
> reflect anyone or any official policy"
> 
> > There is no explicit mention about compiler
> 
> You are right about that, there is no mention about compiler.
> 
> > but trust me it is included
> > in everyones mind. You can ask Dave i am sure he would reject a driver
> > with everything open except the shader compiler.
> 
> How would that work?  Before the GPU driver is accepted, an open
> toolchain also needs to be submitted?
> 
> It's worth it to check out the responses since they not overwhelmingly
> positive and tend to rather be outlining the complicating factors.
> Many if not most say essentially that his stance was simplistic and
> unproductive, slamming the door on the people from whom the solution
> would come.  And keep in mind, this wasn't about what you've made it
> out to be in the first place; this is about open/closed source GPU
> drivers, not toolchains.

You are mixing thing. I say no driver without open source userspace.
For GPU this means something like a mesa driver and mesa driver include
a compiler but not in the form you expect (it is does not provide what
i would call a toolchain). But it can be something else. It could be
a standalone opencl implementation with what we call a finalizer (ie
something that goes from some intermediate representation down to the
hardare ISA).

So if you go look back at new driver submission like Adreno or Vivante.
They provided link to the open source driver they submited to mesa along
their kernel patchset posting.

For FPGA this would mean a tool that can map something like VHDL,Verilog
or even something lower level like a list of lut equation with a netlist
between them (and flip-flop and other blocks). So mapping this down to
the bitstream. It is call a toolchain for FPGA so that's the word i did
use.

> >> The current patchset doesn't have anything to do with FPGA toolchains
> >> but you're using this patchset as a platform to talk about toolchain
> >> issues.
> >
> > Well Intel inclusion of FPGA triggered my curiosity and when that patchset
> > came accross my inbox i did wonder where the open source userspace was and
> > went looking for it to no avail. So this isn't against a specific patchset
> > but more broadly against the whole drivers/fpga/ story. Sorry if this was
> > not clear.
> >
> >
> >> It sounds like you are opposed to any kernel support of loading images
> >> on FPGAs until all vendors have opensource toolchains.
> >
> > Yes that is what i am saying. They are different standard in the kernel
> > and i would rather have one clear standard about driver needing proper
> > open source userspace to go along with any upstream driver.
> 
> Deleting drivers/fpga wouldn't be a step forward to the openness you seek.

I am not saying let delete this. Ok it is there, i dislike that fact, but
it is there. I am asking: is this allowed for FPGA ? If so why ? Do everyone
understand the risks of accepting this ? ...

Now if community believe that we should only accept kernel code with open
source userspace bits then community can say no more changes to drivers/fpga
until you have said open source bits. That would send a clear signal.

Silently accepting drivers/fpga/ with no clear rules leave everyone in the
dark. People that wish to see only driver with open source userspace knows
that company will be happy to stay in this status quo and won't do anything
toward open source. Thinking differently would be utterly naive. A company
will not do something unless there is a clear incentive to do so.

Cheers,
Jérôme

[toc] | [prev] | [next] | [standalone]

#1625356

> Well Intel inclusion of FPGA triggered my curiosity and when that patchset
> came accross my inbox i did wonder where the open source userspace was and
> went looking for it to no avail. So this isn't against a specific patchset
> but more broadly against the whole drivers/fpga/ story. Sorry if this was
> not clear.
> 
> 
> > It sounds like you are opposed to any kernel support of loading images
> > on FPGAs until all vendors have opensource toolchains.  
> 
> Yes that is what i am saying. They are different standard in the kernel
> and i would rather have one clear standard about driver needing proper
> open source userspace to go along with any upstream driver.

So Red Hat will stop shipping any hardware with loadable firmware ?

No I thought not 8)

I think you need to be much clearer what you are talking about. The GPU's
load closed firmware. The sound cards load closed firmware. The pieces we
demand are open (with the exception of the rather strange position
Debian takes) are the actual pieces you need to use the device on the
Linux side - so the 3D libraries, 2D acceleration libraries, wifi
interfaces, audio playback and so on.

The FPGA bitstreams are and always have been counted as firmware (nothing
here is new except that existing systems load FPGA firmware via
devicetree at boot rather than dynamically). That's true of the Xilinx
drivers, the many FPGA drivers for existing ARM and other processor
platforms containing FPGA today that are in kernel.

The second part of the equation is the tools for selecting a bitstream,
and for running whatever accelerator you loaded. Generally that's just a
device that mmap's the accelerator into whatever application wishes to
bash on it. The bits you need to load a bitstream do need to be open, and
the device driver that does the mmio mappingand there will no doubt over
time be other drivers where you do want to kernel mediate your FPGA
functions.

Some bitstreams will need their own drivers, others may want to use
existing drivers. Crypto for example if loaded on an FPGA you'd probably
want to go via the kernel crypto hooks and FPGA hardware for some
applications might want to expose gpios, serial ports, virtio etc. For
debug or if I've got a CPU on my bitstream I might even want to expose a
standard 16x50 UART to the serial drivers.

Generally though most bitstreams are pretty latency sensitive, often used
for real time work, and just provide a set of registers to any
application wanting to use that service.

(Consider for example a Z80 processor emulator on the FPGA - do you
really want to define kvm hooks for Z80 virtualization, or 6502, or all
the rest us retro folks are going to enable ???

Alan

[toc] | [prev] | [next] | [standalone]

#1625377

On Tue, Apr 18, 2017 at 02:36:06PM +0100, Alan Cox wrote:
> > Well Intel inclusion of FPGA triggered my curiosity and when that patchset
> > came accross my inbox i did wonder where the open source userspace was and
> > went looking for it to no avail. So this isn't against a specific patchset
> > but more broadly against the whole drivers/fpga/ story. Sorry if this was
> > not clear.
> > 
> > 
> > > It sounds like you are opposed to any kernel support of loading images
> > > on FPGAs until all vendors have opensource toolchains.  
> > 
> > Yes that is what i am saying. They are different standard in the kernel
> > and i would rather have one clear standard about driver needing proper
> > open source userspace to go along with any upstream driver.
> 
> So Red Hat will stop shipping any hardware with loadable firmware ?
> 
> No I thought not 8)
> 
> I think you need to be much clearer what you are talking about. The GPU's
> load closed firmware. The sound cards load closed firmware. The pieces we
> demand are open (with the exception of the rather strange position
> Debian takes) are the actual pieces you need to use the device on the
> Linux side - so the 3D libraries, 2D acceleration libraries, wifi
> interfaces, audio playback and so on.
> 
> The FPGA bitstreams are and always have been counted as firmware (nothing
> here is new except that existing systems load FPGA firmware via
> devicetree at boot rather than dynamically). That's true of the Xilinx
> drivers, the many FPGA drivers for existing ARM and other processor
> platforms containing FPGA today that are in kernel.

That is where we disagree. I do not see bitstream as firmware. For instance
now you can run OpenCL on some FPGA, so this is exactly like GPU we should
request open source stack from OpenCL down to bitstream.

 
> The second part of the equation is the tools for selecting a bitstream,
> and for running whatever accelerator you loaded. Generally that's just a
> device that mmap's the accelerator into whatever application wishes to
> bash on it. The bits you need to load a bitstream do need to be open, and
> the device driver that does the mmio mappingand there will no doubt over
> time be other drivers where you do want to kernel mediate your FPGA
> functions.

For me this is not enough (tool to load bitstream).

Jérôme

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web