OSDev.org

I'm trying to understand what is the next step I should take once I am in protected mode, with a simple GDT loaded (null, code and data descriptors). I see that a better choice than the GDT for memory protection (specially when dealing with programs requiring more memory than available), is the so called MEMORY PAGING.
I read here and there about it but there are still some doubts that I need explained, like:
1. If I already have the GDT created, can I enable paging? I mean, are these two sequential steps or I must choose one or another for my memory mapping? I already used the GDT so I can jump to the 32-bit section of my code.
2. If I'm not wrong, the trick that allows big programs to run, even if the available memory is not enough, is to store some of the memory on the disk. Is this something that I must handle? I mean, at the moment I don't even have a driver created for my HDD so I can write/read from it. Does it mean that before enabling memory paging I should make possible reading/writing to disk?
If this sounds weird is because, like I said, I am a little confused. I think these things are quite simple to understand, once that you see them from the correct perspective, which is what I am trying.

Thanks!

alexbnc wrote:1. If I already have the GDT created, can I enable paging? I mean, are these two sequential steps or I must choose one or another for my memory mapping? I already used the GDT so I can jump to the 32-bit section of my code.

In theory you can enable/disable paging at any time, however as you develop more complex system there are other things that might rely on paging (e.g. running process) and you need to take care, this is very similar to the "stop the world" scenario.

Anyway, you just need to make sure the MMU can address the same physical memory before and after changing addressing mode, search for identity mapping for an example.

alexbnc wrote:2. If I'm not wrong, the trick that allows big programs to run, even if the available memory is not enough, is to store some of the memory on the disk. Is this something that I must handle? I mean, at the moment I don't even have a driver created for my HDD so I can write/read from it. Does it mean that before enabling memory paging I should make possible reading/writing to disk

If this is your first kernel, I would recommend not to think about swap memory - reduce complexity so that you can actually implement something.
Perhaps after version 3.0 you gain more experience and you'll know how to handle it.

Thanks. So, the page-table is stored in the MMU and once I enable it the processor will receive the memory addresses from there, I suppose.
The GDT divides the entire memory into null (protection against null segment registers), code and data (and if you want something else, you can add it). The IDT is the table which you create in order to handle interrupts (if you don't create it and something bad happens, I suppose you get Triple Fault or something). The LDT is a memory descriptor table for each process. All these information is saved in the CPU's special registers (GDTR, LDTR, IDRT). On the other side the page-table is related to the MMU (at least on Intel). Does that mean that the processor won't care about the GDT anymore once memory paging is enabled? I hope I'm not saying nonsense, I just want to see this correctly.

Anyway, for now I will create a driver for the disk, I thinks is the next step to do in my case. Thanks

1. Segmentation and paging are not alternatives, they are different concepts which can be used together. You still need a GDT when you use paging, but it is common to arrange it so that very few segments are defined and memory is treated as one large, flat address space.

2. Paging, as often used to mean virtual memory, i.e. storing memory on disk is not the paging we are talking about here (but if you want to implement it memory paging certainly helps). Paging in this sense means that we use a logical address space which is mapped to the actual physical pages. Two adjacent logical pages need not map to adjacent physical pages. Advantages of this include (i) processes can only see physical pages mapped to in their page table; this allows very strong protection of memory; (ii) two different processes can map the same logical address to different physical pages - all programs could start at the same logical address but not interfere with each other; (iii) it makes it easy to swap memory to disk as the page table entries include flags to tell whether a page has been accessed and whether it exists in memory - i.e. whether it is mapped to a physical page; (iv) you can space different parts of memory (code, data, stack, etc. very far apart, logically, giving them room to grow without stepping on each other - if you need to extend the stack, for example, just map another page to it; (v) and more.

3. The page tables are not stored in the MMU, they are stored in normal physical memory. The MMU handles the translation of logical addresses to physical addresses using these tables.

In short, if you use paging (highly recommended) you still need a GDT, but it can be a very simple one. You will constantly be creating and destroying page tables as processes are created and destroyed. It is a very dynamic setup.

Thanks!
I suppose next step would be a memory manager. I have to define more descriptors in my GDT for user applications. GDT describes the entire memory and it can refer not necessarily to segments but also to pages, as I understand. So, before enabling virtual memory I need a GDT to know what is kernel code, data for the kernel, user code and data for the user code. I don't need LDT because I want to create a memory manager to handle the memory pages for my programs, no matter what level of privilege they belong to. Hope I'm right

My GDT right now:

The full details of paging can be found in the Intel and AMD manuals, but they can be a little cryptic and hard going. You might like to have a look at this article I found: http://www.makelinux.net/books/ulk3/und ... P-2-SECT-4 . In fact, the whole book that it is part of would probably be interesting reading for a prospective OS developer.

I must admit that I found it a bit difficult to get my head around the concept of paging when I first started looking at it, but it's logical enough once you get the idea. One thing that you do need to keep in mind is that the page tables are stored in memory too, so you need some means to access them (to create them in the first place, and to make new entries or alter existing ones). One technique is to map the whole physical address space - well that much of it that corresponds to the RAM in the system - to a particular logical address space accessible to the kernel only. So you could use, for example, the logical address 0x80000123 when you want to address physical address 0x123. That sounds like a lot of storage dedicated to this part of the page table, but when you look at it it really doesn't take up that much space. Because page tables are arranged as a heirarchy it is easy to efficiently create "sparse" mappings like this.

I think to really be sure that you understand paging you have to get your hands dirty and try it. I can guarantee 100% that you will get loads of Page Faults first time you try, which mean that you are trying to access a logical address that isn't properly mapped; that's where a good debugger and/or a PF interrupt routine that will print out the contents of the registers helps. The system will tell you, via the fault, what address you were executing and what address you were trying to access when it faulted, whether it was a read or write access, etc. And the debugger will let you examine memory, in particular your page tables. All goodies that help you pinpoint an error.

I am studying intel 386 microprocessors and i was just confused about relationship between gdt and paging . iansjack's answer cleared things up a bit for me but I have to be sure about these before going any further i think. Can anyone correct my faults? i would appreciate it. So when we loaded CS to point an entry in GDT. It takes base address from descriptor entry and adds up with offset to create an address. If paging is disabled this is a physical address. If paging is enabled thats a virtual address and this address is resolved by mmu to a physical address which is a base address of a 4KB page. I want to ask this, is it true that base address from GDT + offset is the virtual address when paging is enabled?

fkernel002 wrote:So when we loaded CS to point an entry in GDT. It takes base address from descriptor entry and adds up with offset to create an address.

true

If paging is disabled this is a physical address. If paging is enabled thats a virtual address and this address is resolved by mmu to a physical address

effectively... actually Intel refers to this address as a linear address in both cases, however if paging is disabled, then the linear address is the same as the physical address, but if paging is enabled, then that linear address goes through the paging translation to become the physical address

which is a base address of a 4KB page.

no, after page translation you have a full address (the page tables contain the base of the 4k page, but the linear address itself translates to a full physical address)


see Intel volume 3A:3.1 (and the attached figure 3-1)

virtual address -> [segmentation] -> linear address -> [paging] -> physical address

What one can do to start to wrap his head around the paging mechanism is to attempt to make a virtual to physical memory translation program (start by making it for 32 bit, then add PAE support, then go to 64). It gets you through the basics (what it is, how the tables work, the differences between 32 bit paging / PAE / 64 bit paging etc) without putting you directly in charge of implementing it. I feel that because I had the chance to work with some parts of the concept before trying to implement it helped me a lot. It doesn't have to be something fancy, it just has to get you through the basics (I implemented it as a driver that translated some of it's functions addresses - easy to write, easy to test with a debugger).

thanks for your replies Combuster,JAAman and zdz. The things are clear in my mind now. I would like to know one last thing that what happens when physical address that obtained by mmu address resolving exceeds the address space indicated in GDT by base and limit. For example base address in descriptor is 0x00000000h and limit is 0x00000h. I know that limit is appended with FFFh so my address space is between 0x00000000h and 0x00000FFF. Does my physical address from page table has to be in this range? or it doesnt relate to descriptor limit and could point anywhere in memory so? I havent started writing code yet so i would appreciate the help

fkernel002 wrote: what happens when physical address that obtained by mmu address resolving exceeds the address space indicated in GDT by base and limit.

nothing

the limit applies to the logical address, not the linear address

in other words, the limit limits the offset within the segment, and has nothing to do with the physical address, it is triggered if you try to access an address too far into the segment (past the end of the segment), and applies to the translation between logical address and linear address, and does not affect the translation between linear address and physical address (which can be larger than the linear address space, if, for instance, you are in PMode using PAE or PSE-36, which will translate the 32-bit linear address into a 36-bit (or larger) physical address)