Avoid moving stack (involving SeaOS, JamesM 2.0)

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.
Dominator
Member
Member
Posts: 25
Joined: Fri Jul 06, 2012 10:52 am

Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Dominator »

Hi all. I'm just refactoring my kernel based on JamesM's tutorials ver. 2.0 and the SeaOS kernel, and many of their code seem pretty similar. Couple of questions:

1. The current code from SeaOS doesn't seem to build. Make complains about "make.deps missing separator".

2. What's the best way to avoid moving stack after initializing paging? Right now, after moving stack, my write access to an auto variable (pid in task.c, if you are familiar with JamesM's tutorials) causes triple fault when I increment its value. Something weird is that I can read its address and value with no problem, but just can't write to it. I've checked that write enabled flags are set when I allocated the pages though. Even not, the page fault handler should report the correct protection violation instead of going into a crazy triple fault. Am I right?

UPDATE: So I added an infinite loop in my PANIC code to avoid triple faulting, however it still seems weird that I can read the variable when the fault handler reports "Page not present".

If anyone from SeaOS (piranha?) or anyone familiar with these code is around, that would be awesome.
User avatar
Nessphoro
Member
Member
Posts: 308
Joined: Sat Apr 30, 2011 12:50 am

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Nessphoro »

It depends on how you design your OS.
I don't even bother with moving and stuff because my kernel runs starting at 0xC0000000 from the start. And each subsequent kernel/user thread gets ESP0 allocated in a different region. Below 0xC0000000 that is.
Dominator
Member
Member
Posts: 25
Joined: Fri Jul 06, 2012 10:52 am

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Dominator »

Nessphoro wrote:It depends on how you design your OS.
I don't even bother with moving and stuff because my kernel runs starting at 0xC0000000 from the start. And each subsequent kernel/user thread gets ESP0 allocated in a different region. Below 0xC0000000 that is.
So you are saying I should start with a higher half kernel? That sounds like a great idea, but I'm just not sure how this can be combined with paging. JamesM's tutorial used identity mapping for the first 4MB, which doesn't seem reasonable... Just a bit confused..
User avatar
Nessphoro
Member
Member
Posts: 308
Joined: Sat Apr 30, 2011 12:50 am

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Nessphoro »

There is a tutorial on the wiki about Higher Half,
Basically you link your kernel to 0xC0000000 and your bootstrap code is PIC (Or link it to 0x100000 whatever) which should enable paging and map first four mb to 0xC0000000 jump there and you got yourself the kernel.

I don't see whats confusing here.
Dominator
Member
Member
Posts: 25
Joined: Fri Jul 06, 2012 10:52 am

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Dominator »

Nessphoro wrote:There is a tutorial on the wiki about Higher Half,
Basically you link your kernel to 0xC0000000 and your bootstrap code is PIC (Or link it to 0x100000 whatever) which should enable paging and map first four mb to 0xC0000000 jump there and you got yourself the kernel.

I don't see whats confusing here.
Thanks for the help, I got the boot part working like a charm. I'm just a bit confused about the paging management later on. Since the kernel now boot with VM on, is there anything special about initializing my own VM management? My thoughts are: the kernel now boots at 3GB, so I can remove my original code for identity mapping the first 4MB when initializing VM, plus the whole relocating stack business. For referenced physical addresses like 0xB8000 for VRAM, I just need to add them by 0xC0000000, right?

Also, to set up my own page directory, do I still need to copy the current address space, filling out the tables by subtracting every address by 0xC0000000?
User avatar
Nessphoro
Member
Member
Posts: 308
Joined: Sat Apr 30, 2011 12:50 am

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Nessphoro »

Yes you just add the offset.
For virtual memory management you have choices:
you can reuse the previous Page Directory or create your own - but note that yes you do need to make sure the addresses in the structure are physical - and in the beginning can be achieved by subtracting the offset - although I would try to steer clear of that as it tends to look ugly at the later stages.
Dominator
Member
Member
Posts: 25
Joined: Fri Jul 06, 2012 10:52 am

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Dominator »

Nessphoro wrote:Yes you just add the offset.
For virtual memory management you have choices:
you can reuse the previous Page Directory or create your own - but note that yes you do need to make sure the addresses in the structure are physical - and in the beginning can be achieved by subtracting the offset - although I would try to steer clear of that as it tends to look ugly at the later stages.
So, if the kernel stack is still in the page directory which got "identity mapped + 0xC0000000", what should be done when cloning the directory? I remember JamesM's tutorial mentioning that these pages should be copied rather than linked, but I'm not sure how this would work out.
User avatar
piranha
Member
Member
Posts: 1391
Joined: Thu Dec 21, 2006 7:42 pm
Location: Unknown. Momentum is pretty certain, however.
Contact:

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by piranha »

Whats your system and what commands did you run to get the make.deps error? And which revision do you have?

-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Dominator
Member
Member
Posts: 25
Joined: Fri Jul 06, 2012 10:52 am

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Dominator »

piranha wrote:Whats your system and what commands did you run to get the make.deps error? And which revision do you have?

-JL

Ubuntu 12.04 with GNU Make 3.81 + GCC 4.6.3. I ran "./configure" and then "make toolchain", which gives "make.deps:1 *** missing separator. Stop.". The kernel version is 0.2-b1, which is the one I checked out via svn from google code.
User avatar
piranha
Member
Member
Posts: 1391
Joined: Thu Dec 21, 2006 7:42 pm
Location: Unknown. Momentum is pretty certain, however.
Contact:

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by piranha »

If I knew the revision number, it'd be easier to pin-point the error. Also, if you checked out from the old SVN repo (code.google.com/p/microsea), then its old code (I recently started a new project page and repo, so yeah). Other than that, try updating the code base, removing make.deps and try again.

-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Dominator
Member
Member
Posts: 25
Joined: Fri Jul 06, 2012 10:52 am

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Dominator »

piranha wrote:If I knew the revision number, it'd be easier to pin-point the error. Also, if you checked out from the old SVN repo (code.google.com/p/microsea), then its old code (I recently started a new project page and repo, so yeah). Other than that, try updating the code base, removing make.deps and try again.

-JL

Should be r105, at least it's the latest one from seaos-kernel but not microsea.
User avatar
piranha
Member
Member
Posts: 1391
Joined: Thu Dec 21, 2006 7:42 pm
Location: Unknown. Momentum is pretty certain, however.
Contact:

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by piranha »

Same problem after deleting make.deps and running make again? You could also try running 'make deps', and if that doesn't work, 'sh tools/nodeps.sh'
Edit: just found an error in the nodeps.sh script. Its fixed in r106.

-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Dominator
Member
Member
Posts: 25
Joined: Fri Jul 06, 2012 10:52 am

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Dominator »

piranha wrote:Same problem after deleting make.deps and running make again? You could also try running 'make deps', and if that doesn't work, 'sh tools/nodeps.sh'
Edit: just found an error in the nodeps.sh script. Its fixed in r106.

-JL
Still not working. The generated make.deps file looks like "kernel/config.okernel/console.okernel/kernel.o..." etc. IOW there's no whitespace between the objects, which doesn't seem correct...
User avatar
piranha
Member
Member
Posts: 1391
Joined: Thu Dec 21, 2006 7:42 pm
Location: Unknown. Momentum is pretty certain, however.
Contact:

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by piranha »

Well, I checked out a fresh copy, and I can't reproduce the bug. Running tools/nodeps.sh should generate empty deps files, so that will allow you to compile it...

Did you check out from the kernel repo only, or did you grab all three of the repos?

-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Dominator
Member
Member
Posts: 25
Joined: Fri Jul 06, 2012 10:52 am

Re: Avoid moving stack (involving SeaOS, JamesM 2.0)

Post by Dominator »

piranha wrote:Well, I checked out a fresh copy, and I can't reproduce the bug. Running tools/nodeps.sh should generate empty deps files, so that will allow you to compile it...

Did you check out from the kernel repo only, or did you grab all three of the repos?

-JL
I svn checkouted from the kernel repo only.. Is that the problem?

Also I'm confused by the difference between page_directory and pd in virtual.c ... Also, I can't see how page_tables is being allocated memory for.. Right now I'm getting a page fault when I try to update some entry in page_tables...

They are at very high virtual addresses, which are obviously not in the identity mapped region. I can see memory being allocated for page_directory entires in vm_map, but how entries in page_tables became accessible seems non-obvious to me..
Post Reply