Guru Meditation (VERR_VMX_INVALID_GUEST_STATE) in the FreeBSD boot loader => fixed in SVN

[mslw]

Booting a newly created VM with the FreeBSD 12.3 ISO from ​https://download.freebsd.org/releases/amd64/amd64/ISO-IMAGES/12.3/FreeBSD-12.3-RELEASE-amd64-disc1.iso gives the attached Guru Meditation.

This is a regression in VirtualBox 7.

I've looked at what causes it and found the following.

1. The HM status is:

   00:00:05.485406 CPU[0]: VT-x info:
   00:00:05.485406   HM error           = 0x23a (570)
   00:00:05.485407   rcLastExitToR3     = VERR_VMX_INVALID_GUEST_STATE
   00:00:05.485409   Guest VMCS active
   00:00:05.485410     Real-on-v86 active = true
   00:00:05.485410       EFlags  = 0x7
   00:00:05.485411       Attr CS = 0x9b
   00:00:05.485412       Attr SS = 0xc093
   00:00:05.485412       Attr DS = 0xc093
   00:00:05.485413       Attr ES = 0xc093
   00:00:05.485413       Attr FS = 0xc0f3
   00:00:05.485414       Attr GS = 0xc0f3
   

2. The above HM error 570 is VMX_IGS_V86_GS_LIMIT_INVALID and indeed the gs register has an invalid limit=ffffffff while the CPU is in real mode:

   00:00:05.481475 gs={0000 base=0000000000000000 limit=ffffffff flags=0000c0f3} cr0=00000010 cr2=00000000
   

3. The eip=00009568 in the report is the real mode interrupt handler for Int 0x28 (IRQ8 = RTC) from FreeBSD's ​btx.S.

4. This interrupt is generated while the CPU is stopped in the hlt instruction inside the 0x86 case of int15_function in src/VBox/Devices/PC/BIOS/system.c.

5. The problem doesn't happen in VirtualBox 6.1.40 because that case of int15_function didn't use hlt (changed in r87784).

6. int15_function is called from protected mode using Int 0x31 (v86int) from ​`delay`.

7. Running with the VM debugger shows that the limit=ffffffff in the segment registers starts from where Int 0x31 switches to real mode in ​btx.S.

[mslw]

VBox.log from the crash

[mslw]

Someone else reported it here: ​https://forums.virtualbox.org/viewtopic.php?f=4&t=107762

[fth0]

Adding myself to the watchlist by writing a meaningful comment: ;)

I find it interesting that in both cases the GS limit check is hit, because the FS limit check (and others) before that were not hit. The timing seems to be somewhat reproducible. When I engaged in the forum thread, I didn't analyze it as far as you did here. Kudos for the detailed bug report.

[mslw]

Yes, I wondered about FS as well. Then I looked at the macro HMVMX_CHECK_BREAK and saw why...the break just exits from the macro's own do...while, not the outer one!

[bird]

Scheduling bug. We didn't check if HM could run the guest state after injecting an interrupt. Just committed a fix. Will be included in the next 7.0.x build.

[fth0]

This issue should be fixed in the VirtualBox test builds 7.0.5r154910 and newer.

[@…]

A critical error has occurred while running the virtual machine and the machine execution has been stopped.

[galitsyn]

Hello,

We just released VirtualBox 7.0.6. This issue should be fixed in this version. You can download it from https://www.virtualbox.org/wiki/Downloads.