OSDev.org

So as with most good commercial documentation, we find a glaring contradiction.

mystran wrote: 4. it is quite safe assumption that they won't bother tweaking the MMU on every switch to/from the process manager.

Why is this a safe assumption? I see no reason why the page directory for the system process can't map the higher half with read/write access for CPL3.

This is all just interesting design speculation though. Your point about interfaces is very true nonetheless.

Colonel Kernel wrote: Why is this a safe assumption? I see no reason why the page directory for the system process can't map the higher half with read/write access for CPL3.

Now, if you give CPL3 access to the higher half of address space, then yeah, it's almost sane. You still need to invalidate TLB's (or whatever) for that portion of address space twice (once for grant, once for revoke).

But there is little point in doing so, unless you also prevent the process manager from seeing the lower portion of the address space. And if you do this, you have lost most of the benefits of having it in the system process in the first place. In fact, it would probably be cheaper just to switch the address space at this point.

In case of x86, small address spaces can be more efficiently supported, if we also use the segmentation feature. But that's hardly portable, and if you aren't going to have protection for your process manager on most platforms, then why have it on one? It has to work securely without that anyway.

note that if all the process manager does is to maintain other's address space, it doesn't necessarily need to access TLBs itself: the TLB will actually be flushed when returning to the calling process

As a result, one could make a level-3 process manager for roughly the same cost as a level-0-in-a-separate-address-space manager.

Pype.Clicker wrote: note that if all the process manager does is to maintain other's address space, it doesn't necessarily need to access TLBs itself: the TLB will actually be flushed when returning to the calling process

Now, when I read this, I see two possibilities:
1. The process managers lives in a totally separate address space. Hence, to return, a context switch happens, which flushes the TLBs.
2. The kernel implements some scheme that 'diffs' the old and the new mappings, and invalidates the relevant TLBs.

Now, what about the kernel mappings? Do we only let the process manager touch the page tables, and only map those page tables that don't contain kernel pages? (This actually doesn't sound like an awful idea.)

Or if we use some kind of tricky diffing scheme then ofcourse we can just as well protect the kernel part once we've there.

Finally, in QNX specifically the process manager lives in the system process, and is therefore present in every address space.

As a result, one could make a level-3 process manager for roughly the same cost as a level-0-in-a-separate-address-space manager.

Eh, yeah, but it'd still be slower than a level-0-in-every-address-space manager.