OS working in Qemu but not in VirtualBox

[LIC]

I don't understand why my OS is working perfectly fine with Qemu but I always get a "GuruMeditation" with Virtual Box...
Here is a link to the code https://github.com/leonard-limon/osdev

According to VirtualBox's log, a Triple Fault occurs. I could figure out that it goes into Guru Meditation when I call a function after having loaded the new GDT for my kernel.
It currently fails when I call "print_ok" in the gdt.c file but it also does the same with a call to a different function (I tested with other functions, and whatever the function, it fails).

By the way VirtualBox is loading the kernel from an .iso that is loaded as a floppy (as in Qemu). Here is the VirtualBox log file : https://github.com/leonard-limon/osdev/ ... Box%20Logs


Do you have any idea why my kernel is not working in Virtual Box?

[iansjack]

The fact that the code fails on any function call indicates a probable stack problem. Run the code under a debugger and single-step at the failure point, paying particular attention to the values of ss and esp.

I'm not sure how useful the log is, but it shows esp as being outside the range of the selector in ss.

[Klakap]

Try set up the GDT in assembler(this is my code, edit it as you need):

Code: Select all

gdt:

gdt_null:
   dq 0
gdt_code:
   dw 0FFFFh
   dw 0
db 0
db 10011010b
db 11001111b
db 0
gdt_data:
   dw 0FFFFh
   dw 0
db 0
db 10010010b
db 11001111b
db 0
gdt_end

gdt_desc:
   db gdt_end - gdt
   dw gdt

;load gdt
xor ax, ax
mov ds, ax
lgdt [gdt_desc]

;you can entry to protected mode here

;set stack
mov ax, 08h
mov ds, ax
mov ss, ax
mov esp, 090000h

I have tested that this code works in Qemu and Virtualbox.

[MichaelPetch]

I didn't look at your code but your log has this:

00:00:05.934290 eax=0000005b ebx=00007d81 ecx=0001ffb8 edx=000038b9 esi=00000000 edi=0000fff0
00:00:05.934293 eip=000028b0 esp=0001ff30 ebp=0001ff58 iopl=0 rf nv up di nt zr ac pe cy
00:00:05.934295 cs={0008 base=0000000000000000 limit=ffffffff flags=0000c099} dr0=00000000 dr1=00000000
00:00:05.934299 ds={0010 base=0000000000000000 limit=000fffff flags=00004093} dr2=00000000 dr3=00000000
00:00:05.934301 es={0010 base=0000000000000000 limit=000fffff flags=00004093} dr4=00000000 dr5=00000000
00:00:05.934320 fs={0010 base=0000000000000000 limit=000fffff flags=00004093} dr6=ffff0ff0 dr7=00000400
00:00:05.934323 gs={0010 base=0000000000000000 limit=000fffff flags=00004093} cr0=00000011 cr2=00000000
00:00:05.934325 ss={0018 base=0000000000000000 limit=00000fff flags=0000c097} cr3=00000000 cr4=00000000

What is interesting here is that you have a stack (SS) segment with a selector that apparently has a descriptor limit of 0xfff (last line) yet ESP is outside the limit at 1ff30. In general is there a reason why your code segment is a flat 4gb address space but your DS and SS aren't? QEMU doesn't check all memory accesses (nordoes it check all access rights) to see if you have read/written beyond a segment limit so it will appear to work while virtualbox likely won't be so forgiving. I'd expect that if you ran your kernel in QEMU using the -enable-kvm option that this would likely fail.

I happened to look at your code and noticed you have two sets of GDT routines (they are also different). Quite a few duplicates overall. Did you post your current project?

[LIC]

Thank you for your replies. I changed the GDT descriptors permission field and the GDT is now loading correctly.

However, there is now a bug when copying instructions to load a task in memory. Again everything works fine in Qemu (even with -enable-kvm option) but I get an "Invalide Opcode" exception in Virtual Box at address 0x5200, which i don't understand because the kernel cannot jump there as there is no code here... I tried to disassemble the .img file with ndisasm but could no spot any "jmp 0x5200".

Link to my source code:
https://github.com/leonard-limon/osdev

Do you have any idea why things do not work the same way in Qemu and virtual box ?

[MichaelPetch]

I suggested there are problems with your source code that will not allow it to compile/link. If you want people to look at your code base, would be nice to be able to build it. I recommend you git clone your repository in a completely new directory and try to build your project to see if it works. As it is there all multiple definitions of the same functions that will cause linking to fail. There are also problems with calling `print_ok` with no parameters when it appears it needs 1 argument. Also noticed that there are warnings that you misspelled aligned as alligned in some places.

[LIC]

I am sorry, i am quite new to GitHub so i thought that dragging and dropping file would remove the old ones. So i created another repository, this one should compile with no problem!

https://github.com/leonard-limon/osdev2/

[MichaelPetch]

Looking at your code you don't seem to have enabled the A20 line? Your new code seems to still restrict the stack segment limit and places ESP outside it.

[LIC]

Looking at your code you don't seem to have enabled the A20 line?

I am sorry but I do not understand what you mean by "the A20 line"

[MichaelPetch]

There is an OSDev wiki entry about it: https://wiki.osdev.org/A20_Line

[LIC]

Ok, I tested if A20 is enable in Qemu and in VirtualBox. In deed, in Qemu it IS enabled and in VirtualBox it IS NOT !
Do you think that after enabling A20 on VirtualBox it should fix everything?

Thank you for giving me the link about the A20 line because I did not know about this at all...

[LIC]

Ok I did the Keyboard Controller trick in VirtualBox and everything seems to be working like in Qemu, thank you so much!

[MichaelPetch]

Ok, I tested if A20 is enable in Qemu and in VirtualBox. In deed, in Qemu it IS enabled and in VirtualBox it IS NOT !
Do you think that after enabling A20 on VirtualBox it should fix everything?

Thank you for giving me the link about the A20 line because I did not know about this at all...

I think you have other bugs, but the primary one causing issues was the A20.

I noticed that some of your assembler code clobbers non-volatile registers, and a similar problem in some of your inline assembly where you clobber a register without adding the register to a clobber list. I suspect there are a bunch of smaller bugs that cause you to Pag Fault if you build with GCC optimisations on (-O3). I generally find that wit optimizations on you can find more insidious bugs that you may not necessarily see with them off.

[LIC]

I noticed that some of your assembler code clobbers non-volatile registers

Are you referring to register "eax" in load_gdt function for example?

problem in some of your inline assembly where you clobber a register without adding the register to a clobber list

Is adding an extra ":" enough ?
Like this:

Code: Select all

// save ebp
u32 ***curr_ebp, *stack_ptr;
__asm__("mov %%ebp, %%eax; mov %%eax, %0" : "=m" (curr_ebp) :: "%eax");

And is it necessary to specify witch register to add to the clobber list or GCC knows witch one to add to the clobber list?

Pag Fault if you build with GCC optimisations on (-O3)

In deed when I add this option I get a page fault, thanks for the piece of advice, I'll track the new bugs now.