Anyone got working long mode in Virtualbox?

[turdus]

Ok, I'm fed up with this sh*t. Some mysterious error come up sometimes in VirtualBox, but only in VirtualBox (qemu, bochs, real machine fine). So I decided to debug it. After several nights, I ended up in debugging the exception handlers, because random faults happened (mostly PF) when I enabled interrupts, and I wanted to track down the instruction that caused it. For some reason, my own in-kernel debugger caused another fault (which is impossible, it's written in a way to avoid that (each exception handler checks the inpanic variable). It can only happened if IST1 pointed kernel stack is not available, but I've triple checked that, and it pointed to the top of the first page of userspace where i wanted it).

Code: Select all

macro		exception_code		err, handler
{
if err
		pop			qword [sys.arch.cpu.excerr]
end if
		cmp			byte [panichandler.inpanic], 0
		jnz			.noexc
		cli
		clsavectx
...

Anyway I started to use VirtualBox's built-in debugger (which lack the step-by-step execution feature, gives me errors all the time, as well as modifying guest's registers, so it's really pain to use).
Look what I've found:

Code: Select all

Welcome to the VirtualBox Debugger!
Current VM is 155db000, CPU #0
VBoxDbg> 
dbf event: Fatal error! (hyper)
.eax=00000000 .ebx=00000000 .ecx=00000000 .edx=00000000 .esi=00000000 .edi=00000000
.eip=00000000 .esp=ff5c8000 .ebp=00000000 .iopl=0 nv up di pl nz na pe nc
.cs=fff8 .ds=fff0 .es=fff0 .fs=0000 .gs=0000 .ss=fff0              .eflags=00000000
Failed to disassemble instruction, skipping one byte.
u: error: Too many disassembly failures. Giving up: VINF_SUCCESS

FTW? Fatal error in hypervisor? But what about my guest vm?

Code: Select all

VBoxDbg> rg64
rax=0000000000102232 rbx=ffffffffffffffff rcx=000000000018f0ff rdx=0000000000000000
rsi=65726f63202d205a rdi=000000000000d3e7 r8 =72617453202d205c r9 =0000000000192005
r10=00ff53f000ff53f0 r11=0000000000191007 r12=000000000001e045 r13=0000000000196007
r14=00000000000103ef r15=000000018f000001 iopl=0 rf nv up di pl zr na po nc
rip=000000000001a794 rsp=0000000040000fd4 rbp=000000018f000001
cs=0010 ds=001b es=001b fs=001b gs=001b ss=0000                     rflags=00210046
%000000000001a794 50                      push rax
VBoxDbg> dg
0008 DataRW Bas=00000000 Lim=f0000000 DPL=0 P  A  G     AVL=0 L=0
0010 CodeEO Bas=00000000 Lim=00000000 DPL=0 P  NA       AVL=0 L=1
0018 DataRW Bas=00000000 Lim=f0000000 DPL=3 P  A  G     AVL=0 L=0
0020 CodeEO Bas=00000000 Lim=00000000 DPL=3 P  NA       AVL=0 L=1
0028 Tss64B Bas=0000000040000000 Lim=00000068 DPL=0 P  B         AVL=0 R=0
0034 VERR_INVALID_SELECTOR
VBoxDbg> di 0d
000d Trap64 Sel:Off=0010:000000000001a780     DPL=3 P
VBoxDbg> 

Code segment is a long mode segment, ok, rip points to the appropriate isr, that's fine. But rsp looks unaligned? That's more than unlikely. So I disassembled the code...

Code: Select all

VBoxDbg> u 1a780
%000000000001a780 8f 05 8a 18 ff ff       pop dword [0ffff188ah wrt rip]
%000000000001a786 80 3d 4e 67 ff ff 00    cmp byte [0ffff674eh wrt rip], 000h
%000000000001a78d 0f 85 b3 f9 ff ff       jne -00000064dh (0000000000001a146h)
%000000000001a793 fa                      cli
%000000000001a794 50                      push rax
%000000000001a795 53                      push rbx
%000000000001a796 51                      push rcx
%000000000001a797 52                      push rdx
%000000000001a798 56                      push rsi
%000000000001a799 57                      push rdi

And my mind blow up (almost). How on earth could it pop 4 bytes from stack in long mode? Intel manuals more than clear on this one...

Code: Select all

8F/0       POP r/m64     Valid     N.E.      Pop top of stack into m64; increment stack pointer. Cannot encode 32-bit operand size.

and

Code: Select all

operand-size attribute of the current code segment deter- mines the amount the stack pointer is incremented (2, 4, 8 bytes).

This bugbag succeeded to interpret "pop" as dword in long mode.

Because of this, and many other annoying problems, I hereby declare that I officially drop VirtualBox support for my OS. Sayonara!

[Brynet-Inc]

VirtualBox is unsupported by OpenBSD as well, it's a piece of crap.

[qw]

One of those rare cases where the bug really isn't your own fault. Clever debugging!

[Nable]

What version of VirtualBox do you use? I.e., is it the most recent version?
And if it's the up-to-date version, did you file bugreport?

[turdus]

What version of VirtualBox do you use? I.e., is it the most recent version?

Of course up-to-date.

Code: Select all

$ VirtualBox --help
Oracle VM VirtualBox Manager 4.1.8

And if it's the up-to-date version, did you file bugreport?

No, because it requires an oracle registration (not virtualbox forum or similar), and others have reported the problem already (not the "why" though). Feel free to report it if you like.