OSDev.org

Ok, to be honest, I dislike paging. But I realize it is essential to accomplish what I want. But anyway, this is what I was thinking...

The kernel is, for the most part, unpaged. It uses a flat segment, and uses physical addresses to access other processes data..
(also I use a lower-half kernel)
Applications however, are paged. They have a segment starting at like 0x20000 or somewhere in there and a limit to the top of the address space. Paging is then used so that the same virtual memory location refers to different physical locations(hence, running two applications with the same virtual address)

I never intend for users to have access to the kernel, so why should their GDT allow it even in virtual addresses..

Also, when their is a ring3>ring0 task switch(segment change) will the new 0x0000 be covered by paging or not? this is what I'm confused about..

But anyway, this just seems like a good way to me(if it's possible) but I feel it is flawed.

Does anyone see any problems with this approach?

when paging is on, both kernel and userspace are affected by it.

I am aware, but is it overly expensive to turn paging on and off frequently?

Yes, everytime you turn paging off and on the processor must flush it's TLB entries. That means that the next time the computer needs to access a memory address it must pull the paging tables from main memory and that takes time. When you don't turn paging on and off it doesn't have to flush the buffers and the address can be pulled directly from the TLB.

You could look at trying something like identity mapping for the kernel where every virtual page is mapped 1 to 1 to its physical page ie 0x1000 actually accesses 0x1000.

so it's possible to quickly change from identity paging to mapped paging? more so than turning paging on and off anyway?

As far as I know having a separate page directory for the kernel (in order to facilitate identity mapping) will cost as much time as just turning off paging each time.

Honestly, just changing the CR3 register flushes the TLB, (there are some exceptions) so turning paging on and off would have about the same effect as changing tasks every time. To me it just makes more sense to have the kernel mapped into every processes address space. I use 3gb and up for my kernel but it really doesn't matter where. This way when you have to access the kernel its quick and easy and involves no address space switches.

so most OSs out there change CR3 at each task switch, correct? so by disable and reenabling paging, I really would not get a performance hit compared to other OSs(at least task switching, it might be expensive in system calls)

The performance of every system call would be comparable to a context switch between processes yes. Plus you would have the added complexity of finding a good way to turn off paging. There is no jump to physical address as I turn off paging. You would need a stub that is located at the same physical and virtual address that turned off paging and jumped to the kernel, then re-enabled paging before returning to the program.

Then there's the problem of physical memory fragmentation. With virtual memory the adjacent pages might be mapped to non-adjacent physical pages. So in your kernel if you had to read 4 pages worth of data you might have to stop reading from say page 6 and jump to page 22 or so on.

If used correctly paging makes a lot of things a whole lot more simple.

I think (double check the Intel manuals to be sure) that when you change CR3, TLB entries marked as "global" are not flushed, but when you disable paging, all TLB entries are flushed. If this is true, it would be an excellent reason not to frequently enable and disable paging.

yes, that is completely correct (generally the kernel pages are marked as global, as they will be exactly the same in all page directories)

really, there are a lot of disadvantages to not using paging, and its a lot more complicated to use it partially (as you are suggesting) -- actually, paging is quite simple once you understand it, though a lot of people want to cheat like this when they are first learning about it

if you use paging throughout all, you will find there is not really any difference in the way your kernel is written, and if you identity-map your kernel then you dont even need anything different for setup -- but as your OS grows, you will likely find you were glad you used paging after all


as for making the virtual memory addresses for the kernel available, there really isnt any point to this, since paging will already prevent higher rings from accessing the kernel space, and it only complicates things more by using both segmentation and paging to provide exactly the same thing

You can also use 4M-size pages for the identity mapping of the kernel, and 4K mapping for userspace. This actually has advantages, because the 4M mappings and the 4K mappings use "a completely different TLB." So the two modes do not flush each other's entries at all.