I got this panic running the testsuite QEMU (with KVM acceleration on a Linux host)
sys/fs/tmpfs/sizes_test:big -> passed [3.585s]
sys/fs/tmpfs/trail_slash_test:main -> passed [0.971s]
sys/fs/tmpfs/truncate_test:basic -> passed [1.071s]
sys/fs/tmpfs/times_test:rename -> passed [2.684s]
panic: Unregistered use of FPU in kernel
cpuid = 4
time = 1613595474
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0051a70820
vpanic() at vpanic+0x188/frame 0xfffffe0051a70870
panic() at panic+0x43/frame 0xfffffe0051a708d0
trap() at trap+0x273/frame 0xfffffe0051a709e0
calltrap() at calltrap+0x8/frame 0xfffffe0051a709e0
--- trap 0x16, rip = 0xffffffff81059ffe, rsp = 0xfffffe0051a70ab0, rbp = 0xfffffe0051a70ac0 ---
sse42_crc32c() at sse42_crc32c+0x7e/frame 0xfffffe0051a70ac0
readsuper() at readsuper+0x120/frame 0xfffffe0051a70b00
ffs_sbget() at ffs_sbget+0x91/frame 0xfffffe0051a70b70
g_label_ufs_taste_common() at g_label_ufs_taste_common+0x79/frame 0xfffffe0051a70bb0
g_label_taste() at g_label_taste+0x1a6/frame 0xfffffe0051a70c90
g_new_provider_event() at g_new_provider_event+0x9a/frame 0xfffffe0051a70cb0
g_run_events() at g_run_events+0x176/frame 0xfffffe0051a70cf0
fork_exit() at fork_exit+0x80/frame 0xfffffe0051a70d30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0051a70d30
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 13 tid 100074 ]
Stopped at kdb_enter+0x37: movq $0,0x1292e4e(%rip)
If you turn off acceleration, or use different hypervisor or bare metal, do you
see the same problem?
I believe this is a hypervisor bug, OS cannot/should not do anything there.
This seems to happen with TCG as well, so it's not KVM. Possibly a generic QEMU bug then?
Note: this is QEMU running with as `qemu-system-x86_64 -M accel=tcg -cpu Nehalem -smp 8 -m 2048 -nographic -drive if=none,file=/local/scratch/alr48/cheri/output/freebsd-amd64.img,id=drv,format=raw -device virtio-blk-pci,drive=drv`, so possibly related to the -smp option. I have not seen it without QEMU's smp flag.
Note that CRC32 instruction is qualified on SSE4.2, but it does not use any
of FPU registers. It operates on GPR so it does not require saving user context
before executing in kernel.
It should not even cause #NM (Device Not Available) exception at all, according
to SDM. Adding fpu_kern_enter() around it would hugely hit non-buggy environments
like bare metal or non-buggy hypervisors.
Try to report it to QEMU devs.
I just had a look at the QEMU TCG code for crc32 and it does not seem like it can raise anything other than #UD.
Unless of course there is a bug in the decoding logic and it is treating
<+126>: crc32q %rsi,%rbx as a different instruction. GDB says the raw bytes are as follows:
0xffffffff8105a4de <+126>: f2 48 0f 38 f1 de crc32q %rsi,%rbx
0xffffffff8105a4e4 <+132>: f2 48 0f 38 f1 ca crc32q %rdx,%rcx.
So this does sound like it must be a QEMU bug.
Reported upstream as https://bugs.launchpad.net/qemu/+bug/1916269