Crash on Virtual Box; Higherhalf with GDT

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
MDenham
Member
Member
Posts: 62
Joined: Sat Nov 10, 2012 1:16 pm

Re: Crash on Virtual Box; Higherhalf with GDT

Post by MDenham »

This looks very much like it's a VirtualBox bug (specifically, it seems like it's leaving some garbage in its TLB, pointing you at ridiculous places; this would explain why the other thread from a couple of weeks ago mentioned "this works fine if I enable paging first"), rather than something you're doing wrong. I'll spend part of tomorrow seeing if I can track down what would cause this; I kind of want to get some sleep tonight. :D

Combuster: Nah, it's a side effect of how VirtualBox works if you're using either a 64-bit host or guest. All of the addresses get worked on as if they're in 64-bit space, but if the guest is 32-bit, it'll just crop off the first 32 bits. The addend=(....)06567000 bit is more problematic, as that's the "garbage in the TLB" bit I'm talking about. (Specifically, it uses the value in addend as a virtual base of its own, so it's getting added to the addr_code value. I at least managed to track down that particular part of the VirtualBox source.)
User avatar
Griwes
Member
Member
Posts: 374
Joined: Sat Jul 30, 2011 10:07 am
Libera.chat IRC: Griwes
Location: Wrocław/Racibórz, Poland
Contact:

Re: Crash on Virtual Box; Higherhalf with GDT

Post by Griwes »

Currently I'm trying to move my kernel into the higher half using the GDT trick
What for? Why not just properly use paging to do the trick (of putting kernel in higher half, obviously)?
Reaver Project :: Repository :: Ohloh project page
<klange> This is a horror story about what happens when you need a hammer and all you have is the skulls of the damned.
<drake1> as long as the lock is read and modified by atomic operations
Virtlink
Member
Member
Posts: 34
Joined: Thu Jun 05, 2008 3:53 pm
Location: The Netherlands
Contact:

Re: Crash on Virtual Box; Higherhalf with GDT

Post by Virtlink »

Yes you can page the kernel into higher memory. But then all the symbols and pointers are still pretending the kernel is running at 1 MiB, ruining everything. Or you also link your kernel at 3 GiB, but then all the symbols and pointers pretend the kernel is loaded at 3 GiB whereas it is loaded at 1 MiB before you've enabled paging, ruining everything.
User avatar
xenos
Member
Member
Posts: 1121
Joined: Thu Aug 11, 2005 11:00 pm
Libera.chat IRC: xenos1984
Location: Tartu, Estonia
Contact:

Re: Crash on Virtual Box; Higherhalf with GDT

Post by xenos »

You could simply set up paging in a small assembly stub, in which you correct all addresses "by hand" (i.e. add 0xC0000000 where necessary), before you run any C code. This is what my code is doing:

http://xenos.svn.sourceforge.net/viewvc ... iew=markup

Lines 21 - 56 set up paging. tabPGDIR and tabPGTAB are the virtual (higher half) addresses of the initial page directory and first page table.
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
greyOne
Member
Member
Posts: 58
Joined: Sun Feb 03, 2013 10:38 pm
Location: Canada

Re: Crash on Virtual Box; Higherhalf with GDT

Post by greyOne »

Welp, my kernel boots just fine in VBox on an old Dell machine running a 32-bit XP install.
Griwes wrote:
Currently I'm trying to move my kernel into the higher half using the GDT trick
What for? Why not just properly use paging to do the trick (of putting kernel in higher half, obviously)?
That's what I'll stick at this point anyway;
I was hoping for translated addresses from the start, but I'll figure out a different way of doing so.

EDIT:
And, done.
Setting up a basic page directory from the start and everything works.
Post Reply