Re: [dovetail 6.1.y-cip][PATCH 1/3] arm64: fpsimd: dovetail: Hard-disable interrupts inside fpsimd_save_and_flush_cpu_state

[Philippe Gerum <rpm@xenomai.org>]

Florian Bezdeka <florian.bezdeka@siemens.com> writes:

> On Thu, 2025-09-25 at 14:49 +0200, Jan Kiszka wrote:
>> On 25.09.25 14:47, Florian Bezdeka wrote:
>> > On Thu, 2025-09-25 at 14:40 +0200, Jan Kiszka wrote:
>> > > On 23.09.25 20:51, Philippe Gerum wrote:
>> > > > Jan Kiszka <jan.kiszka@siemens.com> writes:
>> > > > 
>> > > > > From: Jan Kiszka <jan.kiszka@siemens.com>
>> > > > > 
>> > > > > Not all callers of this function do that themselves.
>> > > > > 
>> > > > 
>> > > > Are we 100% sure that kvm_arch_vcpu_load_fp() and kvm_arch_vcpu_put_fp()
>> > > > would not benefit from doing that themselves precisely, to create an
>> > > > atomic section around their internal state change _and_ the fpsimd flush
>> > > > op?
>> > > 
>> > > Is kvm on arm64 officially enabled for oob (-preemption), or are we
>> > > patching blindly here? If no one was looking at kvm yet, then you might
>> > > be right. If it was reviewed already, then this here is just cleaning up.
>> > 
>> > We have
>> > https://gitlab.com/Xenomai/linux-dovetail/-/commit/028ad3b2c19ca8a3655577fb34cac7996f166d2a
>> > 
>> > since 6.14 (AFAICT). At the time of writing this was the first kernel
>> > release that used in-kernel FPU. Maybe that changed (thanks to
>> > backports)? Btw: Which version are we talking about right now? 6.1?
>> > 6.12?
>> 
>> All of them.
>> 
>
> In case backporting is considered:
>

We already have 028ad3b2 in [rebase/]6.1.y-cip, I'll pick 97cb63af01de
as well.

> Please also take
>
> 97cb63af01de ("arm64: fpsimd: dovetail: Align with x86 implementation")
>
> into account. Just a "couple of weeks" old and brings some
> optimizations.
>
>

We also need to enable the oob preemption test in switchtest, which was
disabled so far due to lack of support. Now that 028ad3b2 enables safe
preemption of kernel_neon_begin/end sections by oob thread, we should
allow testing this feature in v3 as well with something along these
lines:

diff --git a/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h b/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
index 0958d5e2a..b8c0c39c5 100644
--- a/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
+++ b/kernel/cobalt/arch/arm64/include/asm/xenomai/fptest.h
@@ -10,16 +10,20 @@
 #include <linux/errno.h>
 #include <asm/xenomai/uapi/fptest.h>
 #include <asm/hwcap.h>
+#include <asm/neon.h>
 
 #define have_fp (ELF_HWCAP & HWCAP_FP)
 
 static inline int fp_linux_begin(void)
 {
-	return -ENOSYS;
+	kernel_neon_begin();
+
+	return 0;
 }
 
 static inline void fp_linux_end(void)
 {
+	kernel_neon_end();
 }
 
 static inline int fp_detect(void)

This was just done in v4 by [1], no issue detected afterwards by the
'hectic' test (switchtest equivalent).

[1] https://gitlab.com/Xenomai/xenomai4/linux-evl/-/commit/0396a52a9b3dc352ef10e6a9d2ed096718ef5d80

-- 
Philippe.