Bug 253617

Summary:	ffs_sbget: panic: Unregistered use of FPU in kernel
Product:	Base System	Reporter:	Alex Richardson <arichardson>
Component:	kern	Assignee:	Alex Richardson <arichardson>
Status:	Closed Not A Bug
Severity:	Affects Only Me	CC:	cem, fs, kib
Priority:	---	Keywords:	crash
Version:	CURRENT
Hardware:	Any
OS:	Any
URL:	https://bugs.launchpad.net/qemu/+bug/1916269
Bug Depends on:
Bug Blocks:	263979

Description Alex Richardson freebsd_committer

2021-02-18 11:01:09 UTC

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>

Comment 1 Konstantin Belousov freebsd_committer

2021-02-19 12:45:02 UTC

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.

Comment 2 Alex Richardson freebsd_committer

2021-02-19 12:48:21 UTC

This seems to happen with TCG as well, so it's not KVM. Possibly a generic QEMU bug then?

Comment 3 Alex Richardson freebsd_committer

2021-02-19 12:50:20 UTC

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.

Comment 4 Konstantin Belousov freebsd_committer

2021-02-19 12:55:39 UTC

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.

Comment 5 Alex Richardson freebsd_committer

2021-02-19 16:11:00 UTC

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.

Comment 6 Alex Richardson freebsd_committer

2021-02-19 17:10:13 UTC

Reported upstream as https://bugs.launchpad.net/qemu/+bug/1916269

Comment 7 Kubilay Kocak freebsd_committer

2022-05-15 01:53:03 UTC

^Triage: Assign to committer that resolved