Crash on Virtual Box; Higherhalf with GDT

[greyOne]

Currently I'm trying to move my kernel into the higher half using the GDT trick, and I've run into a couple of issues.
As usual, the issue only occurs on VirtualBox, so it's probably some incredibly stupid mistake on my part,
Yet after 4 days, I've not been able to find it.

I've been looking at the info VirtualBox dumps after the crash, and as far as I can see, everything is in order;

Code: Select all

Guest CPUM (VCPU 0) state: 
eax=2bad0010 ebx=0002bd20 ecx=0001e200 edx=0001e200 esi=0002be9f edi=0002bea0
eip=c0100050 esp=00067eb4 ebp=00067ec4 iopl=0         nv up di pl zr na pe nc
cs={0008 base=0000000040000000 limit=ffffffff flags=0000c09b} dr0=00000000 dr1=00000000
ds={0010 base=0000000040000000 limit=ffffffff flags=0000c093} dr2=00000000 dr3=00000000
es={0010 base=0000000040000000 limit=ffffffff flags=0000c093} dr4=00000000 dr5=00000000
fs={0010 base=0000000040000000 limit=ffffffff flags=0000c093} dr6=ffff0ff0 dr7=00000400
gs={0010 base=0000000040000000 limit=ffffffff flags=0000c093} cr0=00000011 cr2=00000000
ss={0010 base=0000000040000000 limit=ffffffff flags=0000c093} cr3=00000000 cr4=00000000
gdtr=000000000010002e:0017  idtr=0000000000000000:ffff  eflags=00000002

My GDT values seem to have been loaded correctly, and the registers all seem to be fine.
I've checked the instruction pointer and that also is set correctly:

Code: Select all

c0100050 <higher_half>:
c0100050:	bc 00 b0 10 c0       	mov    $0xc010b000,%esp
c0100055:	e8 06 00 00 00       	call   c0100060 <kmain>
c010005a:	eb fe                	jmp    c010005a <higher_half+0xa>
c010005c:	00 00                	add    %al,(%eax)

The address being loaded into ESP is properly paged in, and should be fine as well.

VirtualBox isn't being very descriptive on what is actually causing the crash, so it's been a pain to pinpoint.
I'm just wondering if there's something blatantly obvious that I might've overlooked.

Cheers.

[Gigasoft]

At this point SS:ESP points to 0x40067eb4. Are you sure that this is what you intended? Personally, I would not bother with this scheme, as there is not much to do at this point besides setting up page tables and enabling paging.

[greyOne]

I assume so; the stack is located in the kernel's BSS section.
I also don't have the issue in bochs, VMWare or VirtualPC so it's probably not the address.
Furthermore it - as far as I see - refers to 0xC0067EB4.

[MDenham]

Furthermore it - as far as I see - refers to 0xC0067EB4.

Right now it's (SS.base = 0x40000000) + ESP (=00067eb4), so it's not pointing to the correct place at all, as Gigasoft said.

You aren't, by any chance, setting SS's selector a few instructions away from where you set ESP, are you? (If memory serves - and I may actually only be thinking of older processors here - faults aren't checked on the instruction immediately after a MOV to SS, specifically so that you can get SP/ESP/RSP set appropriately on that next instruction.)

[greyOne]

Furthermore it - as far as I see - refers to 0xC0067EB4.

Right now it's (SS.base = 0x40000000) + ESP (=00067eb4), so it's not pointing to the correct place at all, as Gigasoft said.

But it is.
0x40000000 + 0xC010B000 = 0x10010B000
Which exceeds the boundaries of a 32-bit it. The leading bit it lost,
And thus: 0x0010B000
We properly point to the physical address of the stack.

That value, 0067eb4, is the arbitrary stack that was there BEFORE I moved the value into ESP.
The value being moved into the ESP register is 0xC010B000.
Which hints to me that I'm crashing at the jumt to higher_half not at stack assignment instruction.

Paging isn't enabled yet, so this should be fine.

I did try playing around with the values,
But all that resulted in was it not working anywhere because of the predictable page fault.

[MDenham]

Furthermore it - as far as I see - refers to 0xC0067EB4.

Right now it's (SS.base = 0x40000000) + ESP (=00067eb4), so it's not pointing to the correct place at all, as Gigasoft said.

But it is.
0x40000000 + 0xC010B000 = 0x10010B000
Which exceeds the boundaries of a 32-bit it. The leading bit it lost,
And thus: 0x0010B000
We properly point to the physical address of the stack.

Paging isn't enabled yet, so this should be fine.

I did try playing around with the values,
But all that resulted in was it not working anywhere because of the predictable page fault.

It hasn't executed the move into ESP yet, though! Look at the register dump: ESP is currently 00067eb4, not C010B000.

So: your problem is happening before that instruction. Probably on the instruction immediately before it, in fact.

[greyOne]

It hasn't executed the move into ESP yet, though! Look at the register dump: ESP is currently 00067eb4, not C010B000.
So: your problem is happening before that instruction. Probably on the instruction immediately before it, in fact.

Aye, I edited that in as an after thought.

But the only instruction between me assigning ESP and me assigning SS is:

Code: Select all

	jmp 0x08:higher_half

[MDenham]

But the only instruction between me assigning ESP and me assigning SS is:

Code: Select all

	jmp 0x08:higher_half

That's enough to do it. Put your ESP assignment before the jump, and your problem should be fixed.

In general, every move to SS should have a move to SP, ESP, or RSP immediately afterward, unless you're absolutely sure that the old value will be okay.

[greyOne]

But the only instruction between me assigning ESP and me assigning SS is:

Code: Select all

	jmp 0x08:higher_half

That's enough to do it. Put your ESP assignment before the jump, and your problem should be fixed.

In general, every move to SS should have a move to SP, ESP, or RSP immediately afterward, unless you're absolutely sure that the old value will be okay.

But nonetheless VirtualBox is still crashing in the same spot, just after the jump,
Even with the stack assigned before the jump.

[greyOne]

And the updated crash dumps...

Code: Select all

Guest CPUM (VCPU 0) state: 
eax=2bad0010 ebx=0002bd20 ecx=0001e200 edx=0001e200 esi=0002be9f edi=0002bea0
eip=c0100050 esp=c010b000 ebp=00067ec4 iopl=0         nv up di pl zr na pe nc
cs={0008 base=0000000040000000 limit=ffffffff flags=0000c09b} dr0=00000000 dr1=00000000
ds={0010 base=0000000040000000 limit=ffffffff flags=0000c093} dr2=00000000 dr3=00000000
es={0010 base=0000000040000000 limit=ffffffff flags=0000c093} dr4=00000000 dr5=00000000
fs={0010 base=0000000040000000 limit=ffffffff flags=0000c093} dr6=ffff0ff0 dr7=00000400
gs={0010 base=0000000040000000 limit=ffffffff flags=0000c093} cr0=00000011 cr2=00000000
ss={0010 base=0000000040000000 limit=ffffffff flags=0000c093} cr3=00000000 cr4=00000000
gdtr=0000000000100033:0017  idtr=0000000000000000:ffff  eflags=00000002

Here's my setup code this time.

Code: Select all

0010000c <start>:
  10000c:	0f 01 15 2d 00 10 00 	lgdtl  0x10002d
  100013:	66 b8 10 00          	mov    $0x10,%ax
  100017:	8e d8                	movl   %eax,%ds
  100019:	8e c0                	movl   %eax,%es
  10001b:	8e e0                	movl   %eax,%fs
  10001d:	8e e8                	movl   %eax,%gs
  10001f:	8e d0                	movl   %eax,%ss
  100021:	bc 00 b0 10 c0       	mov    $0xc010b000,%esp
  100026:	ea 50 00 10 c0 08 00 	ljmp   $0x8,$0xc0100050

The stack seems to have been assigned properly;
Bochs and the other emulators worked just fine.

I praise whomever may have the patience to actually read this.

EDIT:
Now that I think of it,
It shouldn't make any difference when ESP is being assigned (in preset context).
The stack isn't being touched between assignment of SS and ESP;
The operation in between is LJMP, which doesn't use the stack.

[MDenham]

Out of curiosity, what is the error message VirtualBox is giving?

EDIT: As far as why you want to have ESP set before the jump, it's mostly to ensure that if something is actually going wrong with the jump, you have a valid stack for things to go onto so that you can look at error codes immediately leading up to a triple fault. It's mostly a "this will make debugging (slightly) less of a headache" thing.

[greyOne]

Out of curiosity, what is the error message VirtualBox is giving?

EDIT: As far as why you want to have ESP set before the jump, it's mostly to ensure that if something is actually going wrong with the jump, you have a valid stack for things to go onto so that you can look at error codes immediately leading up to a triple fault. It's mostly a "this will make debugging (slightly) less of a headache" thing.

VERR_REM_VIRTUAL_CPU_ERROR

Is what VB identifies the error as.
I've done searches on the error, but have drawn a blank.

EDIT: I guess you do have a point about the stack,
Although in this scenario, there not all to much debugging to be done with a single jump.
Then again, it's making my life miserable at the given moment.

[MDenham]

Okay, one last request: do you have the log for VirtualBox going, and if so, are its last few lines any more helpful? (I might have an idea of what's going wrong here, and why this seems to occur in conjunction with not having paging enabled in VirtualBox when using higher-half addressing, but I'd need to spend a couple of hours tracing VB's code to make sure I have this right. So, to avoid the potential wild-goose chase, I just want to confirm that the log mentions what I suspect it does.)

[greyOne]

Okay, one last request: do you have the log for VirtualBox going, and if so, are its last few lines any more helpful? (I might have an idea of what's going wrong here, and why this seems to occur in conjunction with not having paging enabled in VirtualBox when using higher-half addressing, but I'd need to spend a couple of hours tracing VB's code to make sure I have this right. So, to avoid the potential wild-goose chase, I just want to confirm that the log mentions what I suspect it does.)

Here's a fresh and complete log file.

https://dl.dropboxusercontent.com/u/51276874/vlog.log

If you actually solve this... I will give you a cookie.

[Combuster]

Trying to execute code with memory type addr_code=0000000100100020

This sounds like a bug in the emulation itself since it's apparently not wrapping around as expected.