How it works: Paging + Multitasking

[Sash]

Currently I've implemented switching into protected mode and support of interrupts in my OS. Now I'm going to implement paging and multitasking. Both software and hardware task switching cause difficulties for me.
1). If we use software task switching we create interrupt gate for timer interrupt. When timer interrupt occurs interrupt handler is called without task switch. Now we must load task context for next task. It is well explained in variety of manuals how to do this. But we are still in address space of previous process and haven't access to all physical memory. How can we get new values for cr3, eip, esp and other registers that must be replaced?
2). If we use hardware task switching we create task gate for timer interrupt. When timer interrupt occurs interrupt handler is called in system task. Anyway system task has its own address space and we haven't access to the whole physical memory. The only way I see is to map system's virtual memory to the physical memory 1:1. But it looks like it's not very optimal.
Maybe I misunderstood something?

[rexlunae]

Most OSes has a globally-mapped chunk of memory in all tasks in which they store the processor-defined tables, kernel code, and other global tables. I recommend creating a process table in this memory space to keep track of the information you need to switch tasks (cr3, stack pointer, etc).

[Sash]

Ok. Another question. How can system access memory of some process and memory where located page directories and page tables? Maybe it should temporarily map this memory to its virtual space? Or better once map all physical memory after boot?

[prajwal]

System means Super Process which is like a Boss.... the page table of the system should have a 1:1 map for full memory so that it can access other processes memory
as rexlunae was mentioning, every process will have a common set of pages mapped into it own page table and page dirs which contains kernel code otherwise u can't use Call Gates which changes only CS register but not PDBR (page table base register) CR3.... Usually call gates are used for system calls....
Further one of the main advantages pages and segmentation is protection and its not wrong to have 1:1 mapping for system Process which runs at RING 0

The kernel code and Data mapped in each user process can have the privilage set to ring 0 in there respective page table entries so that user process cannot acces them even though they are mapped in their own page table and can be accessed by Call Gate Code which uses a CS with DPL = ring0

[rexlunae]

Ok. Another question. How can system access memory of some process and memory where located page directories and page tables? Maybe it should temporarily map this memory to its virtual space?

I prefer to not to modify a process's memory when the context of another process is loaded. Of course, sometimes this is necessary (i.e. for IPCs), and there are a couple of options:

1. You could map the memory of one process into the other. This is a big hassel, but reduces the number of copies you need to perform.

2. You could copy the data into a small kernel buffer, then switch context entirely to the other process, and copy the memory where it needs to be. This is the easier solution, but it is likely to be slower in many cases.

Or better once map all physical memory after boot?

This is an option, and some OSes do this. I don't like this approach because it limits your OS to 4 GB of memory, wastes the space for the page tables, and just isn't useful in my opinion. But that is your decision.

[JAAman]

i agree --i dont like mapping physical memory (it also opens the door for bugs and security breaches) --also remember, the target processes page tables (or other data structure you may be trying to access) may not even be in physical memory (and the limit is not 4GB, its more like 1GB -- you cannot use the entire address space, as you must have room for application and kernel memory)

depending on your design, you may not need to ever alter another processes page tables -- for me, my kernel-global page tables are shared between all processes (therefore, i would only rarely ever need to update multiple processes at the same time), when i need to alter a processes address-space, i add a flag, and when the task handler switches into the process, it triggers a kernel function, which alters the page tables accordingly

[Sash]

Intel manuals are great but some things aren't described well.
Now I thought that interrupt handlers that are called without context switching also must be mapped into every process'es memory at the same address. And this address must be specified in interrupt table. What you can say about this?

[JAAman]

yes -- all int handlers that do not use a task gate (usually most) must be mapped into every address space

usually, the entire kernel (or at least the parts that are frequently used for hard-ints, or syscalls) is mapped into every address space, and this includes the int handlers

when the CPU recieves a hard-int, it pauses what it is doing, and transfers control to the vector listed in the IDT -- if there is a ring change, its handled normally (fetching the destination ring stack from the TSS, and storing the source stack on the destination stack for returning)

therefore, the IDT must always contain valid addresses