You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On hosts whose kernel runs with Intel FRED (Flexible Return and Event Delivery) enabled — e.g. Fedora 44 kernels 7.1.x on Panther Lake CPUs — starting any VM panics the host within a few seconds.
Root cause, established from a kdump capture: after an NMI-caused VM exit, VMMR0 re-raises the NMI toward the host by executing int $2. Under IDT event delivery this is the long-standing correct technique. Under FRED, the CPU delivers it as event type 4 (software interrupt), vector 2, and the kernel's FRED dispatch rejects a software-originated NMI vector as an invalid event.
Environment
CPU: Intel Core Ultra X7 358H (Panther Lake)
OS: Fedora 44; kernel 7.1.4-202.fc44
FRED is active: CPU flag present, asm_fred_entrypoint_* frames in traces
VirtualBox: 7.2.12_RPMFUSION r174389
Panic capture
[ 252.406301] SUPR0GipMap: fGetGipCpu=0x1b
[ 253.295343] vboxdrv: opened /dev/kvm (file refs=1); i_node refs 1
[ 253.295349] vboxdrv: releasing /dev/kvm: cRefs=0 file-refs=1 (before)
[ 253.295350] vboxdrv: g_cSupDrvLnxFsRefs=0 g_pSupDrvLnxFsMnt=0000000000000000
[ 253.297891] vboxdrv: 000000000312126f VMMR0.r0
[ 253.392160] vboxdrv: 0000000022d9660f VBoxDDR0.r0
[ 253.464027] vboxdrv: opened /dev/kvm (file refs=1); i_node refs 1
[ 253.464483] vboxdrv: for vm: VINF_SUCCESS! (rc=0) vm-file-refs=1
[ 271.341777] BUG: invalid or fatal FRED event; event type 4 vector 2 error 0x0 aux 0x0 at 0010:ffffcfb864a26316
[ 271.341783] Oops: Invalid or fatal FRED event: 0000 [#1] SMP NOPTI
[ 271.341787] CPU: 8 UID: 1000 PID: 10326 Comm: EMT-3 Kdump: loaded Tainted: G C O 7.1.4-202.fc44.x86_64 #1 PREEMPT(lazy)
[ 271.341790] Tainted: [C]=CRAP, [O]=OOT_MODULE
[ 271.341790] Hardware name: <snip>
[ 271.341791] RIP: 0010:0xffffcfb864a26316
[ 271.341827] Code: cc cc cc cc f3 0f 1e fa 48 83 ec 08 8c 1c 24 0f 00 2c 24 48 83 c4 08 c3 cc cc cc cc cc cc cc cc cc cc cc cc f3 0f 1e fa cd 02 <c3> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[ 271.341828] RSP: 0018:ffffcfb84dbf7888 EFLAGS: 00000046
[ 271.341830] RAX: 0000000000000008 RBX: ffffcfb86556d000 RCX: 0000000080000202
[ 271.341831] RDX: 0000000080000202 RSI: 0000000000000008 RDI: ffffcfb86556d000
[ 271.341832] RBP: ffffcfb84dbf78b0 R08: 0000000000080bdc R09: ffffffffffffffff
[ 271.341833] R10: 0000000000000000 R11: 02204204207fffff R12: 0000000000000008
[ 271.341834] R13: 0000000000000286 R14: ffffcfb8648525a0 R15: 0000000000000000
[ 271.341834] FS: 00007f9b2cefc6c0(0000) GS:ffff88dc86697000(0000) knlGS:0000001eb2adb000
[ 271.341836] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 271.341837] CR2: 00000172da861000 CR3: 000000033f3c8005 CR4: 0000000108f72ef0
[ 271.341838] PKRU: 55555554
[ 271.341838] Call Trace:
[ 271.341840] <TASK>
[ 271.341845] ? supdrvIOCtlFast+0x87/0xf0 [vboxdrv]
[ 271.341871] ? VBoxDrvLinuxIOCtl_7_2_12+0x56/0xd0 [vboxdrv]
[ 271.341886] ? __x64_sys_ioctl+0xb9/0x100
[ 271.341889] ? do_syscall_64+0xe2/0x560
[ 271.341893] ? __smp_call_single_queue+0xe8/0x1b0
[ 271.341897] ? x2apic_send_IPI+0x42/0x50
[ 271.341900] ? generic_exec_single+0x33/0x180
[ 271.341901] ? smp_call_function_single+0x108/0x140
[ 271.341903] ? VBoxHost_RTMpPokeCpu+0x43/0x60 [vboxdrv]
[ 271.341922] ? __virt_addr_valid+0x83/0x110
[ 271.341924] ? check_heap_object+0x38/0x160
[ 271.341927] ? __check_object_size+0x6f/0xd0
[ 271.341929] ? VBoxHost_RTR0MemUserCopyTo+0x5b/0x80 [vboxdrv]
[ 271.341948] ? VBoxDrvLinuxIOCtlSlow.isra.0+0x146/0x240 [vboxdrv]
[ 271.341961] ? VBoxDrvLinuxIOCtl_7_2_12+0xc6/0xd0 [vboxdrv]
[ 271.341974] ? __x64_sys_ioctl+0xd4/0x100
[ 271.341976] ? do_syscall_64+0x11f/0x560
[ 271.341977] ? __x64_sys_ioctl+0xd4/0x100
[ 271.341978] ? do_syscall_64+0x11f/0x560
[ 271.341980] ? __x64_sys_ioctl+0xd4/0x100
[ 271.341981] ? do_syscall_64+0x11f/0x560
[ 271.341982] ? do_syscall_64+0x11f/0x560
[ 271.341984] ? do_syscall_64+0x99/0x560
[ 271.341985] ? __irq_exit_rcu+0x48/0x100
[ 271.341988] ? asm_fred_entrypoint_user+0x41/0x41
[ 271.341991] </TASK>
Suggested fix
VMMR0's host-NMI dispatch needs invoke fred_entry_from_kvm() instead of executing int $2 when the host kernel runs with FRED enabled.
Workaround
Booting the host with fred=off is a verified workaround on my system.
How can we reproduce this?
Host with a FRED-capable CPU (e.g. Intel Panther Lake) and a kernel that enables FRED on it (Fedora 44 kernel 7.1.x does by default on this hardware)
Install VirtualBox 7.2.12
Start any VM
Wait for the first host NMI to arrive while a vCPU is in guest mode
Did you upload all of your necessary log files, screenshots, etc.?
Yes, I've uploaded all pertinent files to this issue.
Version
7.2.12
Host OS Type
Linux
Host OS name + version
Fedora 44, kernel 7.1.4-202.fc44.x86_64
Host Architecture
x86
Guest OS Type
Windows
Guest Architecture
x86
Guest OS name + version
Windows 10
Component
VMM
What happened?
Summary
On hosts whose kernel runs with Intel FRED (Flexible Return and Event Delivery) enabled — e.g. Fedora 44 kernels 7.1.x on Panther Lake CPUs — starting any VM panics the host within a few seconds.
Root cause, established from a kdump capture: after an NMI-caused VM exit, VMMR0 re-raises the NMI toward the host by executing
int $2. Under IDT event delivery this is the long-standing correct technique. Under FRED, the CPU delivers it as event type 4 (software interrupt), vector 2, and the kernel's FRED dispatch rejects a software-originated NMI vector as an invalid event.Environment
asm_fred_entrypoint_*frames in tracesPanic capture
Suggested fix
VMMR0's host-NMI dispatch needs invoke
fred_entry_from_kvm()instead of executingint $2when the host kernel runs with FRED enabled.Workaround
Booting the host with
fred=offis a verified workaround on my system.How can we reproduce this?
Did you upload all of your necessary log files, screenshots, etc.?