OSDev.org

Hi, im wondering how people deal with updating page tables/page maps or anything else you use for page allocation/mapping of a 2nd (not active) process. This is used when i fork or for pages that have COW access.

I currently have the running proc's page tables at 0xffc00000 (page directory at 0xfffff000) and if i need to modify another proc's page tables i map them to 0xfdc00000 and modify them with vpmap functions as if they were loaded as the current page table at 0xffc00000.

This is working atm but Ive been curious if there might be a better way to modified another proc's pagetables.

Thanks,
B.ZaaR

While that method works very well it means that at most you would be able to work on two processes page tables at once. Make sure that any code that accesses the other processes mapped tables can't be interrupted. Imagine if you changed which tables were mapped in the middle of accessing them.

Right now I plan on having a list of temporary addresses that I can map a single page into. That way the kernel can access any data from another process or multiple other processes.

frank wrote:While that method works very well it means that at most you would be able to work on two processes page tables at once. Make sure that any code that accesses the other processes mapped tables can't be interrupted. Imagine if you changed which tables were mapped in the middle of accessing them.

If you've got a multi-threaded kernel (with one kernel-thread per user-thread) and kernel-mappings copied to every VM context, then you don't need to completely lock the temporary area while the kernel-thread works on page tables, as long as you switch VM context when switching to the kernel-thread (as opposed to only when going back to user-space) and then it's not really much of a problem to let that operation be pre-emptable, as long as you make sure that any page-directory that is actually in use already remains valid while threads using it can be scheduled (doesn't matter for a under-construction process that doesn't have any threads ready yet, though), since every VM context can have a different temporary mapping. You do have to lock the other threads of the same process out of the temporary space though, but you'd kinda have to do that anyway to set everything for CoW.