svn commit: r288492 - head/sys/arm/arm

[Ian Lepore]

On Fri, 2015-10-02 at 13:26 +0000, Konstantin Belousov wrote:
> Author: kib
> Date: Fri Oct  2 13:25:59 2015
> New Revision: 288492
> URL: https://svnweb.freebsd.org/changeset/base/288492
> 
> Log:
>   Do not set 'flush to zero' VFPSCR_FZ bit by default.  The correct
>   implementation of IEEE 754 arithmetic depends on denormals operating
>   correctly.  Both perl test suite and paranoia tripped over the
>   setting.
>   
>   Reported by:	Stefan Parvu <sparvu at kronometrix.org>
>   Discussed with:	andrew
>   Sponsored by:	The FreeBSD Foundation
>   MFC after:	1 week
> 
> Modified:
>   head/sys/arm/arm/machdep.c
>   head/sys/arm/arm/vm_machdep.c
> 
> Modified: head/sys/arm/arm/machdep.c
> ==============================================================================
> --- head/sys/arm/arm/machdep.c	Fri Oct  2 13:21:08 2015	(r288491)
> +++ head/sys/arm/arm/machdep.c	Fri Oct  2 13:25:59 2015	(r288492)
> @@ -1069,7 +1069,7 @@ init_proc0(vm_offset_t kstack)
>  		(thread0.td_kstack + kstack_pages * PAGE_SIZE) - 1;
>  	thread0.td_pcb->pcb_flags = 0;
>  	thread0.td_pcb->pcb_vfpcpu = -1;
> -	thread0.td_pcb->pcb_vfpstate.fpscr = VFPSCR_DN | VFPSCR_FZ;
> +	thread0.td_pcb->pcb_vfpstate.fpscr = VFPSCR_DN;
>  	thread0.td_frame = &proc0_tf;
>  	pcpup->pc_curpcb = thread0.td_pcb;
>  }
> 
> Modified: head/sys/arm/arm/vm_machdep.c
> ==============================================================================
> --- head/sys/arm/arm/vm_machdep.c	Fri Oct  2 13:21:08 2015	(r288491)
> +++ head/sys/arm/arm/vm_machdep.c	Fri Oct  2 13:25:59 2015	(r288492)
> @@ -134,7 +134,7 @@ cpu_fork(register struct thread *td1, re
>  	pcb2->pcb_regs.sf_sp = STACKALIGN(td2->td_frame);
>  
>  	pcb2->pcb_vfpcpu = -1;
> -	pcb2->pcb_vfpstate.fpscr = VFPSCR_DN | VFPSCR_FZ;
> +	pcb2->pcb_vfpstate.fpscr = VFPSCR_DN;
>  
>  	tf = td2->td_frame;
>  	tf->tf_spsr &= ~PSR_C;
> 

Some arm documentation refers to the need for "support code" when the
flush-to-zero option is disabled on VFPv2 hardware (which for us would
be just the RPi I think).  Do we have that support code?  What happens
if it's missing?  I can't actually find any info on exactly what that
support code is supposed to do.  For all I know, we have the required
code in libm.  Or maybe what's needed is exception-handling code in the
kernel.  I can't find any info on what they mean by "support code" in
this context.

I don't think this is an issue for VFPv3 and later hardware.  I've
looked in a few of the TRMs for different cortex-a series processors and
they say the hardware handles all combinations of rounding and flush to
zero without support software.  But we should probably be on the lookout
for reports of misbehaving apps on RPi after this change, just in case
this setting has been protecting us from our ignorance there.

-- Ian