OSDev.org

Hi everyone ! Long time no see...

It's been close to a year since I started designing my OS, and I'm close to having some complete memory management system. I can now allocate arbitrary amounts of memory to the kernel and arbitrary PIDs, kill innocent PIDs, set up shared memory between them... In short, this part is soon completed, and I'm happy I managed to get this far.

But before I close this chapter and start to write automated regression tests to stress-test future patches, there's a last thing which I would like to implement : some code which switches from the kernel's address space to that of another process.

I did not manage to find a relevant part of the AMD doc on the topic of context switches, so I would like to check that my vision of it is correct.

Is that right that when a new value of CR3 is loaded, the CPU does not immediately make the switch to the new address space, but that instead a long jump is necessary before the new value of CR3 is "acknowledged" ? Just like back in the day where I enabled long mode, a long time ago ?

Is that right that when a new value of CR3 is loaded, the CPU does not immediately make the switch to the new address space, but that instead a long jump is necessary before the new value of CR3 is "acknowledged" ? Just like back in the day where I enabled long mode, a long time ago ?

No. Whenever CR3 is reloaded the TLB is immediately flushed (except for global pages). The new context will be used straight away. This means that the code that you are executing must exist in both contexts at the same address.

Okay, thanks ! Now I finally understand what all this "higher-half kernel" thing was about, though I don't understand why Intel and AMD made it work this way

The new context will be used straight away. This means that the code that you are executing must exist in both contexts at the same address.

Any new code loaded will be from the new context. Whatever code is currently queued by the processor will be from the old context: old processors use a prefetch queue which doesn't automatically refresh the moment the copy of code in memory is changed, on those processors a jump is necessary if you want to flush that queue.

It is however not necessary: the restriction for the current code existing in both old and new address space is just for this: to prevent different executions because some code comes from the new context and some code comes from the old context - if both are the same it doesn't matter where it came from. The only "real" restriction is that you need a jump between switching from address spaces and entering code that was newly introduced by the switch, which is practically guaranteed in regular code.

Bochs does this as well: the first instruction after a mov cr3 comes from the old context.

Well, sounds like putting that part of context switching in MM is not a good idea after all, because at the moment I switch CR3 I lose access to all memory allocated by the kernel (if I don't want to map the kernel heap in the address space of all processes. Again, sounds not that smart).

I'm rather going to wait until I've gone further in my multitasking implementation, and then put everything in one single place.