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.
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.)
Crash on Virtual Box; Higherhalf with GDT
- Griwes
- 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
What for? Why not just properly use paging to do the trick (of putting kernel in higher half, obviously)?Currently I'm trying to move my kernel into the higher half using the GDT trick
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
<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
Re: Crash on Virtual Box; Higherhalf with GDT
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.
- xenos
- 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
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.
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.
Re: Crash on Virtual Box; Higherhalf with GDT
Welp, my kernel boots just fine in VBox on an old Dell machine running a 32-bit XP install.
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.
That's what I'll stick at this point anyway;Griwes wrote:What for? Why not just properly use paging to do the trick (of putting kernel in higher half, obviously)?Currently I'm trying to move my kernel into the higher half using the GDT trick
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.