Arch64: Clear VFP state on execve()

[arichardson]

Summary

I noticed that many of the math-related tests were failing on AArch64.
After a lot of debugging, I noticed that the floating point exception flags
were not being reset when starting a new process. This change resets the
VFP inside exec_setregs() to ensure no VFP register state is leaked from
parent processes to children.

This commit also moves the clearing of fpcr that was added in 65618fdda0f27
from fork() to execve() since that makes more sense: fork() can retain
current register values, but execve() should result in a well-defined
clean state.

[arichardson]

• Also reset VFP for LInux and FreeBSD32 processes
• Drop unrelated changes

[andrew]

sys/arm64/arm64/machdep.c

557

This should be in vfp.c and should probably call vfp_discard to ensure the hardware state is updated if it's enabled.

[arichardson]

sys/arm64/arm64/machdep.c

557

I just tried moving it to vfp.c but that makes things really ugly if I want to handle !VFP cases. Can't I just add

#ifdef VFP
	vfp_discard(td);
#endif

to the end of this function?

[arichardson]

• Move it to vfp.c

[andrew]

sys/arm64/arm64/vfp.c

413

I don't think this is needed in the !VFP case. It resets values that should only ever be used when the VFP is present and the kernel is built to use it.

If this is the case it could be renamed to vfp_reset_state and moved to be near vfp_save_state.

423

If an interrupt that causes the thread to switch to a new CPU we could end up with an inconsistent state. The simplest fix is to move this critical_enter call to above the bzero. I think it would also work to call vfp_discard first, then clear the state as this will ensure the VFP unit is off.

[arichardson]

Address review feedback

[andrew]

One minor point, feel free to fix without updating the review.

sys/arm64/linux/linux_sysvec.c

60

I don't think this is needed.