Hey people.
After a lot of work and rewriting, Ive hit another problem.
This time its not a bug, its part of the MM_VM components design.
Problem is simply this :
The Zenobit kernel is *completely* virtualized, every address it uses to access any of its structures etc, are not physical addresses - they are all virtual. This is done so that the Kernel 'space' can exist at 0xC0000000 in any userspace address space, the reason why I dont use any physical addresses is so that I dont have to change the address space just to call a system call or something like that, because the kernel is fully operational in any context and doesnt rely upon any addresses except inside of its own 'virtual zone'.
Problem explanation, proper:
When I virtual allocate a page, I allocate a physical page and a Virtual page, then alias them together. If no PDE for the virtual alias exists, I create a PDE for it and plug it into the PDIR At the right location and fill in the neccessary page.
In the Physical world, this all works fine and nicely. In the fully virtualized world, the problem is that while I can access the Page directory itself (Since its in the Kernels aliased zone), I cant access the Directories PDEs to add new aliases. I cant add a new PDE, since that requires me to initialize the PDE, which I Cant do because its a physical address and I cant virtualize it immediately, since to place a virtual address is what probably caused the need to create a new PDE .
Also, the way the MM system works in Zenobit is slightly weird.
Basically : You select a "space" from which to allocate or free a page from.
Space structures track a few things, these things make sure the addresses you get back from the allocation functions are correct for the zone you are allocating for, also track whats in use/free. Explaining the exact operation of the allocation/free system would take sometime, so ill do sometime else.
VM allocations are simply wrappers with support for certain paging things, that automate the needed switches.
My idea:
initial idea : Just page them in when you need them and page htem back out...
more refined idea (after two cups of coffee and some cigarettes, actually... ill be right back, I need more... ... okay, back). :
Basically, we have a centralized pass-through point for Directory operations. I Will call this the Sentinel, since that what I thought of when I coined this.
Anywho, the idea is we have a structure, that has a pointer and 1024 uint32s. pointer is originally primed to whatever page directory we have, it must be a virtualized address to that page directory.
When we say, want to examine a PDE of that directory. We say, EXAMINE(ENTRY_INDEX).
What this does, is first it looks in the structure, to see if the physical addr of that entry is cached. If it is, it uses that to alias the directories virtual page to the entry we want. then it returns the address of the virtual page used as a pass through.
Then we can look through the PDE. If no address is in the Sentinel's list, it will set it first through the Directory.
Second thought, might not need the entry list since we can always just reset back to the originating directory to find the address ourselves.
This idea so far sounds decent to me because :
a) It lets me keep most of the same operation and code as the system I have just spent a week writing.
b) In concept atleast, it doesnt seem too bad.
c) Instead of having to waste a bunch of virtual pages to point to PDEs and stuff, I just have one page that is used for Directory modification and PDE operations (aliasing, sense addr, etc). I care about this especially, since hte Kernels 'virtualized zone' is FINITE. It can use whatever physical address is handed to it for a virtual page, but it only has so many virtual pages. (262,144 pages, infact).
d) We can have a 'prime_directory' function that sets the Sentinel's directory address to the right physical location, so that when we want to examine something, the directory link can be aliased correctly.
Thats my idea to solve this problem.
Suggestions/Criticisms/Ideas of your own/Advice/Thoughts are all welcome.
~Zeii.
Virtualization and the Beast...
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Hi, fellow coffee addict!
In my opinion, your vmm/physical memory management seems quite ok.
How do you connect virtual memory (the address space of a process) to page table entries? B*Tree? or something else?
what about self-referencing the page directory to the last slot in the page directory. Basically the pagedir itself is a page of physical memory.
Mark the following:
Pagedir -> page tables -> page.
To map in a page into your address space, you first allocate a page. Then you look at the proper slot in the Page dir. is a page table already present for that realm ofmemory? No? allocate a page and enter its physical adress in the page dir at the correct slot. then enter the allocated page's physical address at the correct slot in the page table. voila. You've got a mapping.
I recommend you zero out pagedir and pagetables upon allocation, so you have everything defined. I have missed this and found my os so full of unexplainable bugs I canna say.
Don't hesitate to bug me with questions.
In my opinion, your vmm/physical memory management seems quite ok.
How do you connect virtual memory (the address space of a process) to page table entries? B*Tree? or something else?
what about self-referencing the page directory to the last slot in the page directory. Basically the pagedir itself is a page of physical memory.
Mark the following:
Pagedir -> page tables -> page.
To map in a page into your address space, you first allocate a page. Then you look at the proper slot in the Page dir. is a page table already present for that realm ofmemory? No? allocate a page and enter its physical adress in the page dir at the correct slot. then enter the allocated page's physical address at the correct slot in the page table. voila. You've got a mapping.
I recommend you zero out pagedir and pagetables upon allocation, so you have everything defined. I have missed this and found my os so full of unexplainable bugs I canna say.
Don't hesitate to bug me with questions.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
I'm doing the "recursively mapped page directory" thingie, which allows access to all of the paging stuff easily. In gcc,
in a header file, and
in the linker script (assuming GNU ld)
you will be able to access the page tables with meaningful names.
When I manage to screw my head back on (it spun a little too far and came unscrewed when I started thinking about paging), I may be able to help a little more.[/code]
Code: Select all
struct page_t {
unsigned int p:1;
unsigned int w:1;
unsigned int u:1;
unsigned int pwt:1;
unsigned int pcd:1;
unsigned int a:1;
unsigned int resv:1;
unsigned int pat:1;
unsigned int g:1;
unsigned int avail:3; // for my use only
unsigned int base:20;
};
struct page_dir {
unsigned int p:1;
unsigned int w:1;
unsigned int u:1;
unsigned int pwt:1;
unsigned int pcd:1;
unsigned int a:1;
unsigned int dirty:1;
unsigned int ps:1;
unsigned int g:1;
unsigned int avail:3; // for my use only
unsigned int base:20;
};
struct pginfo_t {
struct page_t table[1023][1024];
struct page_dir dir[1024];
};
extern struct pginfo_t pginfo;
Code: Select all
pginfo = 0xffc00000;
you will be able to access the page tables with meaningful names.
When I manage to screw my head back on (it spun a little too far and came unscrewed when I started thinking about paging), I may be able to help a little more.[/code]
My project: Xenon
Code: Select all
struct pginfo_t {
struct page_t table[1023][1024];
struct page_dir dir[1024];
};
extern struct pginfo_t pginfo;
About the only thing that would make it better: a pginfo_2 array or something similar, mapped at 0xFF800000. Why? What if you have to make adjustments to the page table of another process - maybe you are creating a new process, for example. You can map the page directory as the page table at 0xFF800000 just like the one at 0xFFC00000. A bit more confusing, but I have found it very useful.
Mike