Removal of NWFPE in its entirety, and VFP emulation code

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

I have just committed a patch to remove the arch/arm/nwfpe code from
the kernel, and the VFP code emulating the FP operations.

This I have done after it has been brought to my attention by the OSADL's
GPL-violations project that the license for the softfloat library is
incompatible with GPLv2.  This is because the FSF have ruled that
indemnification clauses consitute an "additional restriction" which is
incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
library, and VFP's emulation code is a derivative of softfloat.

This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
longer be able to run userspace with NWFPE support removed.  A possible
solution there is to resurrect FASTFPE support and merge that into
mainline in place of NWFPE.  FASTFPE's hooks are all present in the
kernel, and it should just be a case of adding the FASTFPE code.
However, FASTFPE is probably lacking GDB and signal stack support.
(FastFPE's per-thread workspace is different from NWFPE.)

The situation with VFP is likely less disruptive - only instructions
which aren't implemented in hardware (or, for example, if you ask for
inexact exceptions to be enabled) which are bounced to the software
support code will be affected.  I think OMAP should get away unscathed,
but ARM's implementation will bounce if inexact exceptions are enabled
or in a few corner cases.  Qualcomm is likely to be the worst affected
by this.

Will Deacon has tested debian armhf on a Cortex-A15 with VFP emulation
support removed, which boots successfully.

There is some discussion that needs to happen to investigate possible
solutions to this, which are:

1. Whether we can persuade John to relicense his code.  From what I
   understand from the discussions which have already happened, John
   is against that because he requires the indemnification clause.

   It has been suggested that someone from the community could indemnify
   John, but that doesn't make any sense to me - and it would be hard to
   see how that in itself wouldn't require some kind of additional clause
   which could in itself be seen as an additional restriction.

2. Someone creates a clean-room GPLv2 compatible softfloat
   implementation.

3. Something else?

As I will be away for the next week, and unable to deal with this in any
way, I have taken the only option available to me at the present time and
removed the offending code, which is a change I will be pushing upstream
today.  This brings us back to a compliant situation, to the best of my
knowledge.

Removal of NWFPE in its entirety, and VFP emulation code

[Måns Rullgård]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> The situation with VFP is likely less disruptive - only instructions
> which aren't implemented in hardware (or, for example, if you ask for
> inexact exceptions to be enabled) which are bounced to the software
> support code will be affected.  I think OMAP should get away unscathed,
> but ARM's implementation will bounce if inexact exceptions are enabled

What do you mean by this?  OMAP uses ARM's cores.

> or in a few corner cases.  Qualcomm is likely to be the worst affected
> by this.
>
> Will Deacon has tested debian armhf on a Cortex-A15 with VFP emulation
> support removed, which boots successfully.

Cortex-A9 and later lack hardware support for VFP vector operations.
Any code using these will fail to run without the software emulation.
Of course such code is already horribly slow on these cores and should
be fixed, so perhaps this is not such a terrible thing.

-- 
M?ns Rullg?rd
mans at mansr.com

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > The situation with VFP is likely less disruptive - only instructions
> > which aren't implemented in hardware (or, for example, if you ask for
> > inexact exceptions to be enabled) which are bounced to the software
> > support code will be affected.  I think OMAP should get away unscathed,
> > but ARM's implementation will bounce if inexact exceptions are enabled
> 
> What do you mean by this?  OMAP uses ARM's cores.

OMAP's VFP reports that it never traps to support code for VFP instructions,
so the emulation code is never used on OMAP.

> > or in a few corner cases.  Qualcomm is likely to be the worst affected
> > by this.
> >
> > Will Deacon has tested debian armhf on a Cortex-A15 with VFP emulation
> > support removed, which boots successfully.
> 
> Cortex-A9 and later lack hardware support for VFP vector operations.
> Any code using these will fail to run without the software emulation.
> Of course such code is already horribly slow on these cores and should
> be fixed, so perhaps this is not such a terrible thing.

It's probably not "horribly slow" because unlike NWFPE, I went to great
efforts through my derivation of softfloat to ensure that it was as fast
and efficient as possible on ARM hardware.

If we can identify those which support the full range of VFP instructions
without trapping, but not the vector operations, we could implement the
vector iterations in the support code, executing non-vectored VFP
instructions instead.

But... the problem is identifying those implementations.  We aren't told
all the details about what the implementation supports and what it traps.
:(

Removal of NWFPE in its entirety, and VFP emulation code

[Måns Rullgård]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> 
>> > The situation with VFP is likely less disruptive - only instructions
>> > which aren't implemented in hardware (or, for example, if you ask for
>> > inexact exceptions to be enabled) which are bounced to the software
>> > support code will be affected.  I think OMAP should get away unscathed,
>> > but ARM's implementation will bounce if inexact exceptions are enabled
>> 
>> What do you mean by this?  OMAP uses ARM's cores.
>
> OMAP's VFP reports that it never traps to support code for VFP instructions,
> so the emulation code is never used on OMAP.

That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
(Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.

>> > or in a few corner cases.  Qualcomm is likely to be the worst affected
>> > by this.
>> >
>> > Will Deacon has tested debian armhf on a Cortex-A15 with VFP emulation
>> > support removed, which boots successfully.
>> 
>> Cortex-A9 and later lack hardware support for VFP vector operations.
>> Any code using these will fail to run without the software emulation.
>> Of course such code is already horribly slow on these cores and should
>> be fixed, so perhaps this is not such a terrible thing.
>
> It's probably not "horribly slow" because unlike NWFPE, I went to great
> efforts through my derivation of softfloat to ensure that it was as fast
> and efficient as possible on ARM hardware.

It's several orders of magnitude slower than not using the vector
operations.  This is as one would expect when taking a kernel trap on
almost every instruction.

-- 
M?ns Rullg?rd
mans at mansr.com

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 12:58:09PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> >> 
> >> > The situation with VFP is likely less disruptive - only instructions
> >> > which aren't implemented in hardware (or, for example, if you ask for
> >> > inexact exceptions to be enabled) which are bounced to the software
> >> > support code will be affected.  I think OMAP should get away unscathed,
> >> > but ARM's implementation will bounce if inexact exceptions are enabled
> >> 
> >> What do you mean by this?  OMAP uses ARM's cores.
> >
> > OMAP's VFP reports that it never traps to support code for VFP instructions,
> > so the emulation code is never used on OMAP.
> 
> That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
> (Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.

No.  Both OMAP3 and OMAP4 report that they are VFP subarchitecture 3,
and the VFP subarchitecture 3 never traps to support code for any
instruction (it's the "null subarchitecture" value.)

These are the values reported by various platforms I have access to:

+ * Dove:  VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
+ * OMAP4: VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 1
+ * OMAP3: VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
+ * Pi:    VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5

and "architecture" is actually the VFP subarchitecture number.

Removal of NWFPE in its entirety, and VFP emulation code

[Måns Rullgård]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Wed, Apr 10, 2013 at 12:58:09PM +0100, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> 
>> > On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
>> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> >> 
>> >> > The situation with VFP is likely less disruptive - only instructions
>> >> > which aren't implemented in hardware (or, for example, if you ask for
>> >> > inexact exceptions to be enabled) which are bounced to the software
>> >> > support code will be affected.  I think OMAP should get away unscathed,
>> >> > but ARM's implementation will bounce if inexact exceptions are enabled
>> >> 
>> >> What do you mean by this?  OMAP uses ARM's cores.
>> >
>> > OMAP's VFP reports that it never traps to support code for VFP instructions,
>> > so the emulation code is never used on OMAP.
>> 
>> That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
>> (Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.
>
> No.  Both OMAP3 and OMAP4 report that they are VFP subarchitecture 3,
> and the VFP subarchitecture 3 never traps to support code for any
> instruction (it's the "null subarchitecture" value.)

VFPv3 does not require hardware support for vector operations, and the
Cortex-A9 NEON TRM [1] says this:

   ARMv7 deprecates the use of VFP vector mode. The Cortex-A9 NEON MPE
   hardware does not support VFP vector operations. [...] The Cortex-A9
   NEON MPE provides high speed VFP operation without support code.
   However, if an application requires VFP vector operation, then it
   must use support code.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409i/CHDEEJDB.html

The VFP-only TRM [2] contains similar language:

  The use of VFP vector mode is deprecated in ARMv7.  Vector operations
  are not supported in hardware.  If you use vectors, support code is
  required.

[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0408i/I1019986.html

The Cortex-A15 TRM [3] follows suit:

  Vector operations are not supported.  Any attempt to execute a vector
  operation results in an Undefined Instruction exception.  If an
  application requires VFP vector operation, then it must use VFP
  support code.

[3] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438h/CEGCDBHC.html

In future, if you checked the relevant documentation before making bold
claims, you might avoid making a fool of yourself.

-- 
M?ns Rullg?rd
mans at mansr.com

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 08:23:30PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > On Wed, Apr 10, 2013 at 12:58:09PM +0100, M?ns Rullg?rd wrote:
> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> >> 
> >> > On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
> >> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> >> >> 
> >> >> > The situation with VFP is likely less disruptive - only instructions
> >> >> > which aren't implemented in hardware (or, for example, if you ask for
> >> >> > inexact exceptions to be enabled) which are bounced to the software
> >> >> > support code will be affected.  I think OMAP should get away unscathed,
> >> >> > but ARM's implementation will bounce if inexact exceptions are enabled
> >> >> 
> >> >> What do you mean by this?  OMAP uses ARM's cores.
> >> >
> >> > OMAP's VFP reports that it never traps to support code for VFP instructions,
> >> > so the emulation code is never used on OMAP.
> >> 
> >> That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
> >> (Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.
> >
> > No.  Both OMAP3 and OMAP4 report that they are VFP subarchitecture 3,
> > and the VFP subarchitecture 3 never traps to support code for any
> > instruction (it's the "null subarchitecture" value.)
> 
> VFPv3 does not require hardware support for vector operations, and the
> Cortex-A9 NEON TRM [1] says this:
>
>    ARMv7 deprecates the use of VFP vector mode. The Cortex-A9 NEON MPE
>    hardware does not support VFP vector operations. [...] The Cortex-A9
>    NEON MPE provides high speed VFP operation without support code.
>    However, if an application requires VFP vector operation, then it
>    must use support code.
> 
> [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409i/CHDEEJDB.html
> 
> The VFP-only TRM [2] contains similar language:
> 
>   The use of VFP vector mode is deprecated in ARMv7.  Vector operations
>   are not supported in hardware.  If you use vectors, support code is
>   required.
> 
> [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0408i/I1019986.html
> 
> The Cortex-A15 TRM [3] follows suit:
> 
>   Vector operations are not supported.  Any attempt to execute a vector
>   operation results in an Undefined Instruction exception.  If an
>   application requires VFP vector operation, then it must use VFP
>   support code.
> 
> [3] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438h/CEGCDBHC.html
> 
> In future, if you checked the relevant documentation before making bold
> claims, you might avoid making a fool of yourself.

Oh fuck off, just really fuck off you total dickface.  Really, do you
think that I, being the one who created the VFP support code, haven't
read the VFP documentation?  Christ, you are fucking thick.

Subarchitecture, bits [22:16]
0b0000011
VFP architecture v3 or later with Null subarchitecture. The entire floating-point
implementation is in hardware, and no software support code is required. The
VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
This value can be used only by an implementation that does not support the trap
enable bits in the FPSCR, see Floating-point Status and Control Register
(FPSCR) on page A2-28.

And both OMAP3 and OMAP4 report *this* subarchitecture version.  Maybe
it's you who needs to take a reading lesson instead of making a prat of
*yourself*.

Removal of NWFPE in its entirety, and VFP emulation code

[Måns Rullgård]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Wed, Apr 10, 2013 at 08:23:30PM +0100, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> 
>> > On Wed, Apr 10, 2013 at 12:58:09PM +0100, M?ns Rullg?rd wrote:
>> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> >> 
>> >> > On Wed, Apr 10, 2013 at 12:18:19PM +0100, M?ns Rullg?rd wrote:
>> >> >> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> >> >> 
>> >> >> > The situation with VFP is likely less disruptive - only instructions
>> >> >> > which aren't implemented in hardware (or, for example, if you ask for
>> >> >> > inexact exceptions to be enabled) which are bounced to the software
>> >> >> > support code will be affected.  I think OMAP should get away unscathed,
>> >> >> > but ARM's implementation will bounce if inexact exceptions are enabled
>> >> >> 
>> >> >> What do you mean by this?  OMAP uses ARM's cores.
>> >> >
>> >> > OMAP's VFP reports that it never traps to support code for VFP instructions,
>> >> > so the emulation code is never used on OMAP.
>> >> 
>> >> That is true for OMAP2 (ARM1136/VFP11) and OMAP3 (Cortex-A8).  OMAP4
>> >> (Cortex-A9) and OMAP5 (Cortex-A15) both trap on vector operations.
>> >
>> > No.  Both OMAP3 and OMAP4 report that they are VFP subarchitecture 3,
>> > and the VFP subarchitecture 3 never traps to support code for any
>> > instruction (it's the "null subarchitecture" value.)
>> 
>> VFPv3 does not require hardware support for vector operations, and the
>> Cortex-A9 NEON TRM [1] says this:
>>
>>    ARMv7 deprecates the use of VFP vector mode. The Cortex-A9 NEON MPE
>>    hardware does not support VFP vector operations. [...] The Cortex-A9
>>    NEON MPE provides high speed VFP operation without support code.
>>    However, if an application requires VFP vector operation, then it
>>    must use support code.
>> 
>> [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0409i/CHDEEJDB.html
>> 
>> The VFP-only TRM [2] contains similar language:
>> 
>>   The use of VFP vector mode is deprecated in ARMv7.  Vector operations
>>   are not supported in hardware.  If you use vectors, support code is
>>   required.
>> 
>> [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0408i/I1019986.html
>> 
>> The Cortex-A15 TRM [3] follows suit:
>> 
>>   Vector operations are not supported.  Any attempt to execute a vector
>>   operation results in an Undefined Instruction exception.  If an
>>   application requires VFP vector operation, then it must use VFP
>>   support code.
>> 
>> [3] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438h/CEGCDBHC.html
>> 
>> In future, if you checked the relevant documentation before making bold
>> claims, you might avoid making a fool of yourself.
>
> Oh fuck off, just really fuck off you total dickface.  Really, do you
> think that I, being the one who created the VFP support code, haven't
> read the VFP documentation?  Christ, you are fucking thick.

I'll ignore the insults for now, but you really should consider watching
your tone if you want to be taken seriously.

> Subarchitecture, bits [22:16]
> 0b0000011
> VFP architecture v3 or later with Null subarchitecture. The entire floating-point
> implementation is in hardware, and no software support code is required. The
> VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
> This value can be used only by an implementation that does not support the trap
> enable bits in the FPSCR, see Floating-point Status and Control Register
> (FPSCR) on page A2-28.

This means merely that the implementation never traps on things like
denormal inputs or over/underflow.  It has nothing to do with vector
support.

Both the ARM ARM and the various TRMs make it abundantly clear that
vector operations are optional *and* that some of the cores do *not*
implement them in hardware.

I have also run code with vector operations on A9, and I assure you it
does trap.

> And both OMAP3 and OMAP4 report *this* subarchitecture version.  Maybe
> it's you who needs to take a reading lesson instead of making a prat of
> *yourself*.

Same subarchitecture, different variants.  

-- 
M?ns Rullg?rd
mans at mansr.com

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 09:46:50PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > Oh fuck off, just really fuck off you total dickface.  Really, do you
> > think that I, being the one who created the VFP support code, haven't
> > read the VFP documentation?  Christ, you are fucking thick.
> 
> I'll ignore the insults for now, but you really should consider watching
> your tone if you want to be taken seriously.

Really?  After you accused me of not reading the documentation?  What
planet are you on?  Planet lunacy?  *You* need to learn some bloody
respect.

> > Subarchitecture, bits [22:16]
> > 0b0000011
> > VFP architecture v3 or later with Null subarchitecture. The entire floating-point
> > implementation is in hardware, and no software support code is required. The
> > VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
> > This value can be used only by an implementation that does not support the trap
> > enable bits in the FPSCR, see Floating-point Status and Control Register
> > (FPSCR) on page A2-28.
> 
> This means merely that the implementation never traps on things like
> denormal inputs or over/underflow.  It has nothing to do with vector
> support.

Wrong.  The VFP subarchitecture defines the interface between *VFP
hardware* and the *VFP support code*.  I suggest you read carefully the
chapter in the ARM ARM *before* you make any further comment, and make
yourself look any more a fool than you already do.

Removal of NWFPE in its entirety, and VFP emulation code

[Måns Rullgård]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

>> > Subarchitecture, bits [22:16]
>> > 0b0000011
>> > VFP architecture v3 or later with Null subarchitecture. The entire floating-point
>> > implementation is in hardware, and no software support code is required. The
>> > VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
>> > This value can be used only by an implementation that does not support the trap
>> > enable bits in the FPSCR, see Floating-point Status and Control Register
>> > (FPSCR) on page A2-28.
>> 
>> This means merely that the implementation never traps on things like
>> denormal inputs or over/underflow.  It has nothing to do with vector
>> support.
>
> Wrong.  The VFP subarchitecture defines the interface between *VFP
> hardware* and the *VFP support code*.  I suggest you read carefully the
> chapter in the ARM ARM *before* you make any further comment, and make
> yourself look any more a fool than you already do.

Yet the A9 clearly does trap, just like the TRM says it should.  So
which is more likely, that the TRM and silicon are both wrong, or that
you are wrong?  Perhaps we should put it to a vote.

-- 
M?ns Rullg?rd
mans at mansr.com

Removal of NWFPE in its entirety, and VFP emulation code

[Nicolas Pitre]

On Wed, 10 Apr 2013, M?ns Rullg?rd wrote:

> Yet the A9 clearly does trap, just like the TRM says it should.  So
> which is more likely, that the TRM and silicon are both wrong, or that
> you are wrong?  Perhaps we should put it to a vote.

Instead of encouraging the pissing contest, could you please provide 
compilable example code that would trap so that anyone can test and 
report results back?


Nicolas

Removal of NWFPE in its entirety, and VFP emulation code

[Måns Rullgård]

Nicolas Pitre <nico@fluxnic.net> writes:

> On Wed, 10 Apr 2013, M?ns Rullg?rd wrote:
>
>> Yet the A9 clearly does trap, just like the TRM says it should.  So
>> which is more likely, that the TRM and silicon are both wrong, or that
>> you are wrong?  Perhaps we should put it to a vote.
>
> Instead of encouraging the pissing contest, could you please provide 
> compilable example code that would trap so that anyone can test and 
> report results back?

Certainly.  What's the simplest way of telling whether it trapped?

-- 
M?ns Rullg?rd
mans at mansr.com

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 10:18:42PM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> >> > Subarchitecture, bits [22:16]
> >> > 0b0000011
> >> > VFP architecture v3 or later with Null subarchitecture. The entire floating-point
> >> > implementation is in hardware, and no software support code is required. The
> >> > VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
> >> > This value can be used only by an implementation that does not support the trap
> >> > enable bits in the FPSCR, see Floating-point Status and Control Register
> >> > (FPSCR) on page A2-28.
> >> 
> >> This means merely that the implementation never traps on things like
> >> denormal inputs or over/underflow.  It has nothing to do with vector
> >> support.
> >
> > Wrong.  The VFP subarchitecture defines the interface between *VFP
> > hardware* and the *VFP support code*.  I suggest you read carefully the
> > chapter in the ARM ARM *before* you make any further comment, and make
> > yourself look any more a fool than you already do.
> 
> Yet the A9 clearly does trap, just like the TRM says it should.  So
> which is more likely, that the TRM and silicon are both wrong, or that
> you are wrong?  Perhaps we should put it to a vote.

Look, it's all very simple for those who know how this works, which *you*
plainly don't - but rather than admit that you'll much rather insult
those who do.

- A9 is ARMv7.
- Vector operations are deprecated in ARMv7.
- Whether vector operations are implemented is up to the implementer.
- If they aren't implemented, they will cause an undefined instruction
  exception.
- If the VFP subarchitecture says '3' that means no support code is
  required by the implementation.

All together, that means that on ARMv7, of which Cortex-A9 is one such
implementation, vector operations *are* *deprecated* may or may not be
implement in hardware.  If they are not implemented in hardware *and*
the VFP subarchitecture reports '3', then you _should_ strictly get a
SIGILL for them and not have them executed because they are _deprecated_
*and* _unsupported_ instructions.

The current VFP support code behaviour can *not* be relied upon as being
correct, because it was implemented for VFP9 hardware, and has only been
tweaked so that it apparantly works with later VFP hardware.  There are
a bunch of known errors and problems with it with later VFP hardware,
one of which is providing emulation of all VFP instructions even for
subarch v3.

Subarch v3 _will_ eventually result in no VFP instruction emulation at
all when fixed, and it _will_ provoke a SIGILL instead.

I don't expect you to understand this, and you'll continue whinging.
Feel free, I won't be listening.  I'll be the other side of the country
really not caring in the least what stupid theory you're whining about.

Removal of NWFPE in its entirety, and VFP emulation code

[Måns Rullgård]

Russell King - ARM Linux <linux@arm.linux.org.uk> writes:

> On Wed, Apr 10, 2013 at 10:18:42PM +0100, M?ns Rullg?rd wrote:
>> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>> 
>> >> > Subarchitecture, bits [22:16]
>> >> > 0b0000011
>> >> > VFP architecture v3 or later with Null subarchitecture. The entire floating-point
>> >> > implementation is in hardware, and no software support code is required. The
>> >> > VFP architecture version is indicated by the MVFR0 and MVFR1 registers.
>> >> > This value can be used only by an implementation that does not support the trap
>> >> > enable bits in the FPSCR, see Floating-point Status and Control Register
>> >> > (FPSCR) on page A2-28.
>> >> 
>> >> This means merely that the implementation never traps on things like
>> >> denormal inputs or over/underflow.  It has nothing to do with vector
>> >> support.
>> >
>> > Wrong.  The VFP subarchitecture defines the interface between *VFP
>> > hardware* and the *VFP support code*.  I suggest you read carefully the
>> > chapter in the ARM ARM *before* you make any further comment, and make
>> > yourself look any more a fool than you already do.
>> 
>> Yet the A9 clearly does trap, just like the TRM says it should.  So
>> which is more likely, that the TRM and silicon are both wrong, or that
>> you are wrong?  Perhaps we should put it to a vote.
>
> Look, it's all very simple for those who know how this works, which *you*
> plainly don't - but rather than admit that you'll much rather insult
> those who do.
>
> - A9 is ARMv7.
> - Vector operations are deprecated in ARMv7.
> - Whether vector operations are implemented is up to the implementer.
> - If they aren't implemented, they will cause an undefined instruction
>   exception.
> - If the VFP subarchitecture says '3' that means no support code is
>   required by the implementation.
>
> All together, that means that on ARMv7, of which Cortex-A9 is one such
> implementation, vector operations *are* *deprecated* may or may not be
> implement in hardware.  If they are not implemented in hardware *and*
> the VFP subarchitecture reports '3', then you _should_ strictly get a
> SIGILL for them and not have them executed because they are _deprecated_
> *and* _unsupported_ instructions.

So you're saying the current kernel behaviour of emulating the vector
operations on A9 is in error.  I suppose I could agree with that
(although the system response to an undefined instruction is not
specified by the architecture), and I'm glad you finally admit that some
VFP instructions can indeed trap on ARMv7.

That said, we should still be prepared to handle reports of previously
(apparently) working software starting to break if the emulation is
dropped.

-- 
M?ns Rullg?rd
mans at mansr.com

Removal of NWFPE in its entirety, and VFP emulation code

[Nicolas Pitre]

On Wed, 10 Apr 2013, M?ns Rullg?rd wrote:

> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> 
> > - A9 is ARMv7.
> > - Vector operations are deprecated in ARMv7.
> > - Whether vector operations are implemented is up to the implementer.
> > - If they aren't implemented, they will cause an undefined instruction
> >   exception.
> > - If the VFP subarchitecture says '3' that means no support code is
> >   required by the implementation.
> >
> > All together, that means that on ARMv7, of which Cortex-A9 is one such
> > implementation, vector operations *are* *deprecated* may or may not be
> > implement in hardware.  If they are not implemented in hardware *and*
> > the VFP subarchitecture reports '3', then you _should_ strictly get a
> > SIGILL for them and not have them executed because they are _deprecated_
> > *and* _unsupported_ instructions.
> 
> So you're saying the current kernel behaviour of emulating the vector
> operations on A9 is in error.  I suppose I could agree with that

Given Russell's explanation above that's my opinion too.

> (although the system response to an undefined instruction is not
> specified by the architecture),

It is defined by POSIX.


Nicolas

Removal of NWFPE in its entirety, and VFP emulation code

[Will Deacon]

Hi Russell,

On Wed, Apr 10, 2013 at 11:40:02AM +0100, Russell King - ARM Linux wrote:
> I have just committed a patch to remove the arch/arm/nwfpe code from
> the kernel, and the VFP code emulating the FP operations.

[...]

I just had a play with your for-next branch, and noticed a couple of issues
arising from this:

	1. Removing vfpinstr.h leads to a couple of build failures, as it is
	   still included by arch/arm/kvm/coproc.c (for fmrx, which we should
	   continue to provide) and arch/arm/vfp/vfpmodule.c (similarly, but
	   also fmxr).

	2. vfp.h now contains a bunch of dead function declarations (e.g.
	   vfp_double_normaliseround) which should probably be removed. In
	   fact, the inline functions are unused too, so they could also go.

Will

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 02:21:27PM +0100, Will Deacon wrote:
> Hi Russell,
> 
> On Wed, Apr 10, 2013 at 11:40:02AM +0100, Russell King - ARM Linux wrote:
> > I have just committed a patch to remove the arch/arm/nwfpe code from
> > the kernel, and the VFP code emulating the FP operations.
> 
> [...]
> 
> I just had a play with your for-next branch, and noticed a couple of issues
> arising from this:
> 
> 	1. Removing vfpinstr.h leads to a couple of build failures, as it is
> 	   still included by arch/arm/kvm/coproc.c (for fmrx, which we should
> 	   continue to provide) and arch/arm/vfp/vfpmodule.c (similarly, but
> 	   also fmxr).

Grr, this is why relative include paths are bad news.  It breaks the
localisation of includes.  Okay, I'll add that include back, even
though nothing in arch/arm/vfp will be using it.

I'll leave everything else though... the functions in vfp.h will take
too much time to work out what's required and what isn't, and I don't
have the available bandwidth before I go away to work out what functions
are used and what aren't.

Removal of NWFPE in its entirety, and VFP emulation code

[Nicolas Pitre]

On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:

> I have just committed a patch to remove the arch/arm/nwfpe code from
> the kernel, and the VFP code emulating the FP operations.
> 
> This I have done after it has been brought to my attention by the OSADL's
> GPL-violations project that the license for the softfloat library is
> incompatible with GPLv2.  This is because the FSF have ruled that
> indemnification clauses consitute an "additional restriction" which is
> incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> library, and VFP's emulation code is a derivative of softfloat.
> 
> This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> longer be able to run userspace with NWFPE support removed.  A possible
> solution there is to resurrect FASTFPE support and merge that into
> mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> kernel, and it should just be a case of adding the FASTFPE code.
> However, FASTFPE is probably lacking GDB and signal stack support.
> (FastFPE's per-thread workspace is different from NWFPE.)

A point worth mentioning is the EABI availability since 2006 which moved 
away from FPA completely. A soft-float library in user space is used in 
that case.  Major ARM binary producers including all ARM distros moved 
to EABI with user space soft-float since then as it is order of 
magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
are unlikely to be affected.

So another option here might imply deprecating OABI support entirely, 
given that it is useless without FPA and people keeping current with the 
latest kernel are very likely to already use EABI user space.


Nicolas

Removal of NWFPE in its entirety, and VFP emulation code

[Steve McIntyre]

On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
>On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
>
>> I have just committed a patch to remove the arch/arm/nwfpe code from
>> the kernel, and the VFP code emulating the FP operations.
>> 
>> This I have done after it has been brought to my attention by the OSADL's
>> GPL-violations project that the license for the softfloat library is
>> incompatible with GPLv2.  This is because the FSF have ruled that
>> indemnification clauses consitute an "additional restriction" which is
>> incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
>> library, and VFP's emulation code is a derivative of softfloat.
>> 
>> This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
>> longer be able to run userspace with NWFPE support removed.  A possible
>> solution there is to resurrect FASTFPE support and merge that into
>> mainline in place of NWFPE.  FASTFPE's hooks are all present in the
>> kernel, and it should just be a case of adding the FASTFPE code.
>> However, FASTFPE is probably lacking GDB and signal stack support.
>> (FastFPE's per-thread workspace is different from NWFPE.)
>
>A point worth mentioning is the EABI availability since 2006 which moved 
>away from FPA completely. A soft-float library in user space is used in 
>that case.  Major ARM binary producers including all ARM distros moved 
>to EABI with user space soft-float since then as it is order of 
>magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
>are unlikely to be affected.
>
>So another option here might imply deprecating OABI support entirely, 
>given that it is useless without FPA and people keeping current with the 
>latest kernel are very likely to already use EABI user space.

Plus, OABI is just about dead in major places like glibc too.

Cheers,
-- 
Steve McIntyre                                steve.mcintyre at linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
> On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> 
> > I have just committed a patch to remove the arch/arm/nwfpe code from
> > the kernel, and the VFP code emulating the FP operations.
> > 
> > This I have done after it has been brought to my attention by the OSADL's
> > GPL-violations project that the license for the softfloat library is
> > incompatible with GPLv2.  This is because the FSF have ruled that
> > indemnification clauses consitute an "additional restriction" which is
> > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> > library, and VFP's emulation code is a derivative of softfloat.
> > 
> > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> > longer be able to run userspace with NWFPE support removed.  A possible
> > solution there is to resurrect FASTFPE support and merge that into
> > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> > kernel, and it should just be a case of adding the FASTFPE code.
> > However, FASTFPE is probably lacking GDB and signal stack support.
> > (FastFPE's per-thread workspace is different from NWFPE.)
> 
> A point worth mentioning is the EABI availability since 2006 which moved 
> away from FPA completely. A soft-float library in user space is used in 
> that case.  Major ARM binary producers including all ARM distros moved 
> to EABI with user space soft-float since then as it is order of 
> magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
> are unlikely to be affected.
> 
> So another option here might imply deprecating OABI support entirely, 
> given that it is useless without FPA and people keeping current with the 
> latest kernel are very likely to already use EABI user space.

Unfortunately, I _still_ can't move off OABI.

Removal of NWFPE in its entirety, and VFP emulation code

[Nicolas Pitre]

On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:

> On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
> > On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> > 
> > > I have just committed a patch to remove the arch/arm/nwfpe code from
> > > the kernel, and the VFP code emulating the FP operations.
> > > 
> > > This I have done after it has been brought to my attention by the OSADL's
> > > GPL-violations project that the license for the softfloat library is
> > > incompatible with GPLv2.  This is because the FSF have ruled that
> > > indemnification clauses consitute an "additional restriction" which is
> > > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> > > library, and VFP's emulation code is a derivative of softfloat.
> > > 
> > > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> > > longer be able to run userspace with NWFPE support removed.  A possible
> > > solution there is to resurrect FASTFPE support and merge that into
> > > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> > > kernel, and it should just be a case of adding the FASTFPE code.
> > > However, FASTFPE is probably lacking GDB and signal stack support.
> > > (FastFPE's per-thread workspace is different from NWFPE.)
> > 
> > A point worth mentioning is the EABI availability since 2006 which moved 
> > away from FPA completely. A soft-float library in user space is used in 
> > that case.  Major ARM binary producers including all ARM distros moved 
> > to EABI with user space soft-float since then as it is order of 
> > magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
> > are unlikely to be affected.
> > 
> > So another option here might imply deprecating OABI support entirely, 
> > given that it is useless without FPA and people keeping current with the 
> > latest kernel are very likely to already use EABI user space.
> 
> Unfortunately, I _still_ can't move off OABI.

How can this be helped?


Nicolas

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 02:58:57PM -0400, Nicolas Pitre wrote:
> On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> 
> > On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
> > > On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> > > 
> > > > I have just committed a patch to remove the arch/arm/nwfpe code from
> > > > the kernel, and the VFP code emulating the FP operations.
> > > > 
> > > > This I have done after it has been brought to my attention by the OSADL's
> > > > GPL-violations project that the license for the softfloat library is
> > > > incompatible with GPLv2.  This is because the FSF have ruled that
> > > > indemnification clauses consitute an "additional restriction" which is
> > > > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> > > > library, and VFP's emulation code is a derivative of softfloat.
> > > > 
> > > > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> > > > longer be able to run userspace with NWFPE support removed.  A possible
> > > > solution there is to resurrect FASTFPE support and merge that into
> > > > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> > > > kernel, and it should just be a case of adding the FASTFPE code.
> > > > However, FASTFPE is probably lacking GDB and signal stack support.
> > > > (FastFPE's per-thread workspace is different from NWFPE.)
> > > 
> > > A point worth mentioning is the EABI availability since 2006 which moved 
> > > away from FPA completely. A soft-float library in user space is used in 
> > > that case.  Major ARM binary producers including all ARM distros moved 
> > > to EABI with user space soft-float since then as it is order of 
> > > magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
> > > are unlikely to be affected.
> > > 
> > > So another option here might imply deprecating OABI support entirely, 
> > > given that it is useless without FPA and people keeping current with the 
> > > latest kernel are very likely to already use EABI user space.
> > 
> > Unfortunately, I _still_ can't move off OABI.
> 
> How can this be helped?

I don't think there is a solution - as StrongARM is ARMv4 without Thumb
support, which means that it's incompatible with EABI which uses bx and
blx instructions.

Removal of NWFPE in its entirety, and VFP emulation code

[Imre Kaloz]

On Wed, 10 Apr 2013 21:02:33 +0200, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> On Wed, Apr 10, 2013 at 02:58:57PM -0400, Nicolas Pitre wrote:
>> On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
>>
>> > On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
>> > > On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
>> > >
>> > > > I have just committed a patch to remove the arch/arm/nwfpe code from
>> > > > the kernel, and the VFP code emulating the FP operations.
>> > > >
>> > > > This I have done after it has been brought to my attention by the OSADL's
>> > > > GPL-violations project that the license for the softfloat library is
>> > > > incompatible with GPLv2.  This is because the FSF have ruled that
>> > > > indemnification clauses consitute an "additional restriction" which is
>> > > > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
>> > > > library, and VFP's emulation code is a derivative of softfloat.
>> > > >
>> > > > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
>> > > > longer be able to run userspace with NWFPE support removed.  A possible
>> > > > solution there is to resurrect FASTFPE support and merge that into
>> > > > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
>> > > > kernel, and it should just be a case of adding the FASTFPE code.
>> > > > However, FASTFPE is probably lacking GDB and signal stack support.
>> > > > (FastFPE's per-thread workspace is different from NWFPE.)
>> > >
>> > > A point worth mentioning is the EABI availability since 2006 which moved
>> > > away from FPA completely. A soft-float library in user space is used in
>> > > that case.  Major ARM binary producers including all ARM distros moved
>> > > to EABI with user space soft-float since then as it is order of
>> > > magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users
>> > > are unlikely to be affected.
>> > >
>> > > So another option here might imply deprecating OABI support entirely,
>> > > given that it is useless without FPA and people keeping current with the
>> > > latest kernel are very likely to already use EABI user space.
>> >
>> > Unfortunately, I _still_ can't move off OABI.
>>
>> How can this be helped?
>
> I don't think there is a solution - as StrongARM is ARMv4 without Thumb
> support, which means that it's incompatible with EABI which uses bx and
> blx instructions.

May I ask, if you do LFS or are you using some existing distro? Is patching [1] your toolchain a no-go?


Imre


[1]
https://dev.openwrt.org/browser/trunk/toolchain/gcc/patches/4.7-linaro/830-arm_unbreak_armv4t.patch
https://dev.openwrt.org/browser/trunk/toolchain/gcc/patches/4.7-linaro/840-armv4_pass_fix-v4bx_to_ld.patch

Removal of NWFPE in its entirety, and VFP emulation code

[Aaro Koskinen]

On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
> On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> 
> > I have just committed a patch to remove the arch/arm/nwfpe code from
> > the kernel, and the VFP code emulating the FP operations.
> > 
> > This I have done after it has been brought to my attention by the OSADL's
> > GPL-violations project that the license for the softfloat library is
> > incompatible with GPLv2.  This is because the FSF have ruled that
> > indemnification clauses consitute an "additional restriction" which is
> > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> > library, and VFP's emulation code is a derivative of softfloat.
> > 
> > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> > longer be able to run userspace with NWFPE support removed.  A possible
> > solution there is to resurrect FASTFPE support and merge that into
> > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> > kernel, and it should just be a case of adding the FASTFPE code.
> > However, FASTFPE is probably lacking GDB and signal stack support.
> > (FastFPE's per-thread workspace is different from NWFPE.)
> 
> A point worth mentioning is the EABI availability since 2006 which moved 
> away from FPA completely. A soft-float library in user space is used in 
> that case.  Major ARM binary producers including all ARM distros moved 
> to EABI with user space soft-float since then as it is order of 
> magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
> are unlikely to be affected.

Menuconfig mentions under "Floating point emulation" that "At least one
emulation must be selected". But if I compile my OS with EABI userspace
soft-float I guess I won't actually need to select any emulation,
or have I missed something? (I just checked my configs, and at least
on Kirkwood/openrd I have been already running without any emulation,
so I guess the help text is wrong?)

A.

Removal of NWFPE in its entirety, and VFP emulation code

[Nicolas Pitre]

On Wed, 10 Apr 2013, Aaro Koskinen wrote:

> On Wed, Apr 10, 2013 at 01:30:35PM -0400, Nicolas Pitre wrote:
> > On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:
> > 
> > > I have just committed a patch to remove the arch/arm/nwfpe code from
> > > the kernel, and the VFP code emulating the FP operations.
> > > 
> > > This I have done after it has been brought to my attention by the OSADL's
> > > GPL-violations project that the license for the softfloat library is
> > > incompatible with GPLv2.  This is because the FSF have ruled that
> > > indemnification clauses consitute an "additional restriction" which is
> > > incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> > > library, and VFP's emulation code is a derivative of softfloat.
> > > 
> > > This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> > > longer be able to run userspace with NWFPE support removed.  A possible
> > > solution there is to resurrect FASTFPE support and merge that into
> > > mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> > > kernel, and it should just be a case of adding the FASTFPE code.
> > > However, FASTFPE is probably lacking GDB and signal stack support.
> > > (FastFPE's per-thread workspace is different from NWFPE.)
> > 
> > A point worth mentioning is the EABI availability since 2006 which moved 
> > away from FPA completely. A soft-float library in user space is used in 
> > that case.  Major ARM binary producers including all ARM distros moved 
> > to EABI with user space soft-float since then as it is order of 
> > magnitude faster than FPA emulation.  So 99.99% of ARMv4 and ARMv5 users 
> > are unlikely to be affected.
> 
> Menuconfig mentions under "Floating point emulation" that "At least one
> emulation must be selected". But if I compile my OS with EABI userspace
> soft-float I guess I won't actually need to select any emulation,
> or have I missed something? (I just checked my configs, and at least
> on Kirkwood/openrd I have been already running without any emulation,
> so I guess the help text is wrong?)

It is wrong in the EABI case.  This help text probably predates the 
introduction of EABI.


Nicolas

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 10:00:52PM +0300, Aaro Koskinen wrote:
> Menuconfig mentions under "Floating point emulation" that "At least one
> emulation must be selected". But if I compile my OS with EABI userspace
> soft-float I guess I won't actually need to select any emulation,
> or have I missed something? (I just checked my configs, and at least
> on Kirkwood/openrd I have been already running without any emulation,
> so I guess the help text is wrong?)

Well, it's that way to stop us being flooded with "why does my kernel
stop after mounting the rootfs" questions.  Maybe that can be changed
now, it depends whether we're absolutely certain that there's no FPA
instructions in any binary being run on EABI-only userspaces.

Given that such instructions will still be emulated if they're
encountered, I think we need to have another option to at least report
an error via the kernel message log should a FPA instruction be trapped.

Removal of NWFPE in its entirety, and VFP emulation code

[Nicolas Pitre]

On Wed, 10 Apr 2013, Russell King - ARM Linux wrote:

> On Wed, Apr 10, 2013 at 10:00:52PM +0300, Aaro Koskinen wrote:
> > Menuconfig mentions under "Floating point emulation" that "At least one
> > emulation must be selected". But if I compile my OS with EABI userspace
> > soft-float I guess I won't actually need to select any emulation,
> > or have I missed something? (I just checked my configs, and at least
> > on Kirkwood/openrd I have been already running without any emulation,
> > so I guess the help text is wrong?)
> 
> Well, it's that way to stop us being flooded with "why does my kernel
> stop after mounting the rootfs" questions.  Maybe that can be changed
> now, it depends whether we're absolutely certain that there's no FPA
> instructions in any binary being run on EABI-only userspaces.

It is at least clear according to the EABI documentation. The double 
float word ordering is also defined to be different from FPA's, making 
EABI and FPA incompatible.

> Given that such instructions will still be emulated if they're
> encountered, I think we need to have another option to at least report
> an error via the kernel message log should a FPA instruction be trapped.

Agreed.


Nicolas

Removal of NWFPE in its entirety, and VFP emulation code

[Måns Rullgård]

Nicolas Pitre <nico@fluxnic.net> writes:

> So another option here might imply deprecating OABI support entirely, 

I'd support such a move.

-- 
M?ns Rullg?rd
mans at mansr.com

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 08:25:59PM +0100, M?ns Rullg?rd wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
> 
> > So another option here might imply deprecating OABI support entirely, 
> 
> I'd support such a move.

And your previous reply disqualified your opinions on any subject.
Sorry.  If you want to have a public flame war instead of being
reasonable, you can't expect your opinions to be taken seriously.

Removal of NWFPE in its entirety, and VFP emulation code

[jonsmirl at gmail.com]

On Wed, Apr 10, 2013 at 6:40 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> I have just committed a patch to remove the arch/arm/nwfpe code from
> the kernel, and the VFP code emulating the FP operations.
>
> This I have done after it has been brought to my attention by the OSADL's
> GPL-violations project that the license for the softfloat library is
> incompatible with GPLv2.  This is because the FSF have ruled that
> indemnification clauses consitute an "additional restriction" which is
> incompatible with the GPLv2 section 6.  NWFPE contains the softfloat
> library, and VFP's emulation code is a derivative of softfloat.
>
> This will be very disruptive for ARMv4 and ARMv5 CPUs, which will no
> longer be able to run userspace with NWFPE support removed.  A possible
> solution there is to resurrect FASTFPE support and merge that into
> mainline in place of NWFPE.  FASTFPE's hooks are all present in the
> kernel, and it should just be a case of adding the FASTFPE code.
> However, FASTFPE is probably lacking GDB and signal stack support.
> (FastFPE's per-thread workspace is different from NWFPE.)
>
> The situation with VFP is likely less disruptive - only instructions
> which aren't implemented in hardware (or, for example, if you ask for
> inexact exceptions to be enabled) which are bounced to the software
> support code will be affected.  I think OMAP should get away unscathed,
> but ARM's implementation will bounce if inexact exceptions are enabled
> or in a few corner cases.  Qualcomm is likely to be the worst affected
> by this.
>
> Will Deacon has tested debian armhf on a Cortex-A15 with VFP emulation
> support removed, which boots successfully.
>
> There is some discussion that needs to happen to investigate possible
> solutions to this, which are:
>
> 1. Whether we can persuade John to relicense his code.  From what I
>    understand from the discussions which have already happened, John
>    is against that because he requires the indemnification clause.

Does it work to have him donate the copyright for the code to the FSF?
Then he wouldn't own it anymore and wouldn't need indemnification. FSF
would reissue under GPLv2 since it would be the owner of the copyright
with the ability to relicense.

>
>    It has been suggested that someone from the community could indemnify
>    John, but that doesn't make any sense to me - and it would be hard to
>    see how that in itself wouldn't require some kind of additional clause
>    which could in itself be seen as an additional restriction.
>
> 2. Someone creates a clean-room GPLv2 compatible softfloat
>    implementation.
>
> 3. Something else?
>
> As I will be away for the next week, and unable to deal with this in any
> way, I have taken the only option available to me at the present time and
> removed the offending code, which is a change I will be pushing upstream
> today.  This brings us back to a compliant situation, to the best of my
> knowledge.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
Jon Smirl
jonsmirl at gmail.com

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 02:38:21PM -0400, jonsmirl at gmail.com wrote:
> On Wed, Apr 10, 2013 at 6:40 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > 1. Whether we can persuade John to relicense his code.  From what I
> >    understand from the discussions which have already happened, John
> >    is against that because he requires the indemnification clause.
> 
> Does it work to have him donate the copyright for the code to the FSF?
> Then he wouldn't own it anymore and wouldn't need indemnification. FSF
> would reissue under GPLv2 since it would be the owner of the copyright
> with the ability to relicense.

I don't know - and I'm not going to be able to look at this anymore until
about a weeks time, by which time this thread will be dead and buried,
and I'll have long forgotten about it...

Even if it is transferred to the FSF, that implies a change to the license,
which the copyright holder(s) would have to authorise.  The problem with
that is, if you read the license, it has been developed as part of a much
larger project, with a grant, and there may be strings attached which
prevent that happening.  I'm not saying it's not worth asking the question
though.

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 11:40:02AM +0100, Russell King - ARM Linux wrote:
> I have just committed a patch to remove the arch/arm/nwfpe code from
> the kernel, and the VFP code emulating the FP operations.

It seems that Linus wishes to fight against this, so we'll just have to
wait and see what happens.  Linus is saying that he's perfectly happy
that the licenses _are_ compatible irrespective of what the FSF say.

Removal of NWFPE in its entirety, and VFP emulation code

[Russell King - ARM Linux]

On Wed, Apr 10, 2013 at 11:40:02AM +0100, Russell King - ARM Linux wrote:
> I have just committed a patch to remove the arch/arm/nwfpe code from
> the kernel, and the VFP code emulating the FP operations.

It's time for a status update on this.

There appears to be some confusion over the license under which *our*
version of the softfloat code is licensed under.

The first point to ensure that everyone understands is that the license
which applies to any code is the applicable license at the point the code
was obtained, not *any* subsequent license updates.  If the license is
changed on a code base, it creates a license "fork" - new copies of the
code base are licensed under the new license terms, but older copies
obtained before the fork point remain under the old license terms.

Our version of softfloat was integrated into the kernel a long time ago,
maybe back in December 2000 - it was certainly in mainline in kernel
version 2.2.19.  This work was done as part of Corel's Netwinder team,
hence the name "nw-fpe" or "netwinder fpe".

This version was derived from the version which could be found at:
	http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/softfloat.html
which was licensed as per the documentation within the files you find
in your kernel source today.  Indeed, the license header in these
softfloat files remained untouched until commit 50a23e6eec6f20d55 -
more on that below.

Sometime later, softfloat moved to a different URL:
	http://www.jhauser.us/arithmetic/SoftFloat-2b/SoftFloat-source.txt
and the original URL became invalid.  It is not clear when this happened,
but dates on the new site suggest 2010.  Also, the softfloat license was
changed (maybe around the same time), with the addition of an
indemnification clause.  This indemnification clause *may* make the new
license incompatible with the GPLv2.  However, this clause only applies
to a new copy of the code, and can not be applied retrospectively to
older versions - even though the text of the code may in fact be
identical.

However, certain folk who like to ensure that all URLs in the kernel point
at valid sites decided to fix any broken URLs - including the softfloat
URLs.  So, commit 50a23e6eec6f20d55 (Update broken web addresses in arch
directory.) changed the URLs in our softfloat files to point at the new
URL.  This, on the face of it, is not a problem.  However, the version it
now points at has a different license.

As our version pre-dates the version at the new URL and the license change,
the license under which *our* version remains is the original license which
does *not* have the indemnification cause, and thus our copy of the code
remains GPLv2 compatible.

Therefore, there is no need to remove this softfloat code from the kernel;
there is no license conflict.