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) db>
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
^Triage: Assign to committer that resolved