Date: Wed, 15 Feb 2023 16:08:46 -0800 From: Mark Millard <marklmi@yahoo.com> To: "kd@freebsd.org" <kd@FreeBSD.org>, "wma@freebsd.org" <wma@FreeBSD.org>, dev-commits-src-main@freebsd.org Subject: RE: git: 6926e2699ae5 - main - arm: Add support for using VFP in kernel Message-ID: <3A143148-895F-472B-9AFB-5F1AA0FD1FA0@yahoo.com> References: <3A143148-895F-472B-9AFB-5F1AA0FD1FA0.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kornel Dul=C4=99ba <kd_at_FreeBSD.org> wrote on Date: Sat, 04 Feb 2023 19:22:23 UTC : > The branch main has been updated by kd: >=20 > URL: = https://cgit.FreeBSD.org/src/commit/?id=3D6926e2699ae55080f860488895a2a9aa= 6e6d9b4d >=20 > commit 6926e2699ae55080f860488895a2a9aa6e6d9b4d > Author: Kornel Dul=C4=99ba <kd@FreeBSD.org> > AuthorDate: 2023-02-04 12:59:30 +0000 > Commit: Kornel Dul=C4=99ba <kd@FreeBSD.org> > CommitDate: 2023-02-04 19:21:43 +0000 >=20 > arm: Add support for using VFP in kernel >=20 > 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. >=20 > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A143148-895F-472B-9AFB-5F1AA0FD1FA0>