Will this cause page faults?

[Crazed123]

I've just finished coding some functions and things that manage virtual memory in units of pages (virtual and physical nodes) and contexts, which are collections of virtual page nodes representing entire address spaces, including a page directory. However, I'm suspicious as to the actions of the function BuildPagingInformation(), which computes and sets the paging data in the page directory and page tables. I realize it needs some correction (better error handling, for starters), but I've invested enough mental effort in this thing that I'd like somebody to take a look at it before I go picking at too much.

Basically, if you could please audit TVirtualMemoryContext.BuildPagingInformation() I'd be extremely grateful. I want to know:

1.Will the actions of that code cause page faults due to overwriting a page directory and tables that (assuming worst case) are in use, or will the TLB contain enough local references due to running all that kernel code to stay sane? What can be done if faults would result?
2. Is there a neater, more efficient way to build paging information the hardware needs from the node trees used in software? How about just neater?


And yes, I know I'm using a class. I originally wrote it as a structure with associated functions, but I was passing a pointer or var parameter in so many times I decided to make it a class and have that parameter be implicit.

Thank you for your help, anyone who can read the code and bothers to take a look!

[Cjmovie]

IDK about the other stuff, but writing to an active page directory shouldn't hurt a bit. The big trouble would come if you wrote a new address to the page directory (for a page table) before you've gotten the page table set up at that address, and try to read there.

Also, writing to a live page directory MIGHT not take affect until later - Parts of it are kept in cache and not refreshed until you call a certain command in assembly (forgot it for the moment, it's on bona-fide I think).

Page faults, of course, happen all the time. They ARE recoverable, as windows page-faults whenever a new bit of program data is needed and isn't ready, so it reads it from the hard drive.

[Crazed123]

That's why I asked. I figured if it was cached well enough I could replace any page table entries I wanted and the cache would still keep memory referencfes valid until I flushed it.

Doesn't matter now, as I've deemed the function overcomplicated and removed it in favor a smaller operation that sets the page table entry for one page given a virtual address by finding the corresponding node. If no node is found, the page table entry is set to not present. This function is called automatically whenever a node is deleted.

Thanks anyways!

[Kim]

pMount^.pNextTree:= KGetMem(sizeof(TMountedTree));

Your kgetmem function is it on top of paging? Or does it uses physical pages? Because you are using it in your paging managment code.

[Crazed123]

It's on top of paging, which I set up after the physical MM and before the heap and this precisely for the reason that I'd rather have convenient functions for making VMM nodes and take the extra work of imposing the VMM on top of basic paging structures, which coincidentally seems to work fine.