RE: git: 6926e2699ae5 - main - arm: Add support for using VFP in kernel

Kornel Dulęba <kd_at_FreeBSD.org> wrote on
Date: Sat, 04 Feb 2023 19:22:23 UTC :

> The branch main has been updated by kd:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=6926e2699ae55080f860488895a2a9aa6e6d9b4d
> 
> commit 6926e2699ae55080f860488895a2a9aa6e6d9b4d
> Author: Kornel Dulęba <kd@FreeBSD.org>
> AuthorDate: 2023-02-04 12:59:30 +0000
> Commit: Kornel Dulęba <kd@FreeBSD.org>
> CommitDate: 2023-02-04 19:21:43 +0000
> 
> arm: Add support for using VFP in kernel
> 
> Add missing logic to allow in-kernel VFP usage for ARMv7 NEON.
> The implementation is strongly based on arm64 code.
> It introduces a family of fpu_kern_* functions to enable the usage
> of VFP instructions in kernel.
> Apart from that the existing armv7 VFP logic was modified,
> taking into account that the state of the VFP registers can now
> be modified in the kernel.
> 
> Co-developed by: Wojciech Macek <wma@FreeBSD.org>
> Sponsored by: Stormshield
> Obtained from: Semihalf
> Reviewed by: andrew
> Differential Revision: https://reviews.freebsd.org/D37419
> ---
> lib/libthread_db/arch/arm/libpthread_md.c | 21 ++--
> sys/arm/arm/exec_machdep.c | 49 ++++----
> sys/arm/arm/machdep.c | 1 +
> sys/arm/arm/machdep_kdb.c | 31 ++++-
> sys/arm/arm/swtch-v6.S | 8 +-
> sys/arm/arm/swtch.S | 8 +-
> sys/arm/arm/vfp.c | 182 +++++++++++++++++++++++++++++-
> sys/arm/arm/vm_machdep.c | 6 +-
> sys/arm/include/fpu.h | 7 ++
> sys/arm/include/pcb.h | 5 +
> sys/arm/include/reg.h | 12 +-
> sys/arm/include/vfp.h | 17 +++
> 12 files changed, 293 insertions(+), 54 deletions(-)

[This is a somewhat adjusted version of a note replying
to a Warner note about a panic someone got during a
process coredump that was happening.]

Just a possible point, given recent kernel floating
point work:

I tried to do a typical build and test of some
benchmark programs that I sometimes use that involve
floating point in some of the programs, some use with
multithreading involved. (As FreeBSD and g++ progress
I tend to do this once and a while, not as often on
armv7 as on aarch64.)

On armv7, I now usually get a message about a failure
of an internal cross-check, which also leads to the
program being stopped early. The messaging from run
to run varies what the failure is, but the runs should
not vary and should not fail the cross-checks --and
previously did not, including when I last tried armv7.
(Not recently.)

For the specific example failures, the initial serial
(single thread) test with float involved works but the
following multi-thread test in the same program fails
and causes the program to stop when it notices there
is a problem. (On occasion the cross-check does does
not detect a problem.)

The programs that do not test floating point do not
fail. (Same algorithm on integral types.) These can
involve floating point outside the algorithm
benchmarked, but with no multi-threading involved for
such and no floating point based cross-checks involved.

At this point it is far from obvious to me how I
would trackdown the specifics of what leads to the
failed cross-checks. But the above is suggestive of
there being problems for armv7 handling of saving
and restoring floating point context for
multi-threading in a process, at least. I've no clue
if such are strictly limited to the floating point
values that show up vs. if there might be wider
memory handling problems that result in the process.

===
Mark Millard
marklmi at yahoo.com