KDL: Unexpected exception "SIMD Floating-Point Exception" occurred in kernel mode!

[konrad]

If you run Qemu with SMP larger than 2, Haiku crashes.

This one KDLs: qemu-system-x86_64 -drive file=haiku.img,format=raw -m 8192 -soundhw hda -usb -accel hvf -cpu host -smp 4 -rtc base=utc,clock=host

changing to -smp 2 works.

[konrad]

serial output

[waddlesplash]

​https://xref.plausible.coop/source/xref/haiku/src/add-ons/kernel/bus_managers/usb/Transfer.cpp#230

There's a bunch of floating-point math in there, but no divides by non-constants. That it works with 2 cores but not 4 is especially strange, and likely implies a bug in our multicore logic, or (more likely, since no-one has ever seen this elsewhere) in QEMU's HVF usage

[tqh]

I thought we avoided FP/SIMD in the kernel?

[waddlesplash]

We have never had a policy of avoiding FP. A large number of things in kernel-mode (the USB stack as seen here is one instance) use floating-point math.

We also do not have any policy (or, really, any reason, since SSE2 is part of the baseline x64) to avoid SIMD in the kernel; I think it's enabled (since pdziepak's scheduler changes) inside the bootloader just before the kernel is called. GCC 6+ by default will vectorize certain operations; seems that's what is occurring here.

[tqh]

Do we really save and restore that properly. I think they propably shouldn't be there. I was taught to never ever do that in kernel and think most OS'es avoid it. In PS/2 driver there is even fake FP handling.

[tqh]

Looked it up, saving restoring fp (and simd on 32bit) is so expensive it is not done on context switching. Therefore you need to write code that save/restore them perfetly on all exit cases and without messing up stack order. So it's just something you should avoid. SIMD on 64 bit is fine though.

Havn't looked at our own context-switching though.

[waddlesplash]

As I said already, pdziepak made changes to enable this even earlier in the boot than it was before; we definitely support this properly in kernel mode and many other things would have broken if we didn't: ​https://xref.plausible.coop/source/xref/haiku/src/system/kernel/arch/x86/arch_thread.cpp#250

[waddlesplash]

The PS/2 driver's fake FP probably dates from the days we ran Haiku code under BeOS, which (I don't believe?) supported floating-point, indeed. We can probably get rid of that fake code and use the real thing now.

[tqh]

Ah nice. PS/2 code will be moved out of kernel at some point. Similar code exists in userland already.