[Bug]: Host kernel panic on FRED-enabled kernels

[thomasfedb]

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

• 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?

1. 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)
2. Install VirtualBox 7.2.12
3. Start any VM
4. 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.