Preceding paragraph: -The x86 processor has two distinct memory management mechanisms -that JOS could use to achieve this mapping: -segmentation and paging. -Both are described in full detail in the -80386 Programmer's Reference Manual -and the -IA-32 Developer's Manual, Volume 3. -When the JOS kernel first starts up, -it initially uses segmentation -to establish the desired virtual-to-physical mapping, -because it is quick and easy - -and the x86 processor requires us -to set up the segmentation hardware in any case, -because it can't be disabled! +For now, we'll just map the first 4MB of physical memory, which will +be enough to get us up and running. We do this using the +hand-written, statically-initialized page directory and page table in +kern/entrypgdir.c. For now, you don't have to understand the +details of how this works, just the effect that it accomplishes. Up +until kern/entry.S sets the CR0_PG flag, memory +references are treated as physical addresses (strictly speaking, +they're linear addresses, but boot/boot.S set up an identity mapping +from linear addresses to physical addresses and we're never going to +change that). Once CR0_PG is set, memory references are +virtual addresses that get translated by the virtual memory hardware +to physical addresses. entry_pgdir translates virtual +addresses in the range 0xf0000000 through 0xf0400000 to physical +addresses 0x00000000 through 0x00400000, as well as virtual addresses +0x00000000 through 0x00400000 to physical addresses 0x00000000 through +0x00400000. Any virtual address that is not in one of these two +ranges will cause a hardware exception which, since we haven't set up +interrupt handling yet, will cause QEMU to dump the machine state and +exit (or endlessly reboot if you aren't using the 6.828-patched +version of QEMU). For exercise 7: - and find where the new virtual-to-physical mapping takes effect. - Then examine the Global Descriptor Table (GDT) - that the code uses to achieve this effect, - and make sure you understand what's going on. + and stop at the movl %eax, %cr0. Examine memory + at 0x00100000 and at 0xf0100000. Now, single step over that + instruction using the stepi GDB command. Again, + examine memory at 0x00100000 and at 0xf0100000. Make sure you + understand what just happened. From question 7: - if the old mapping were still in place? - Comment out or otherwise intentionally break - the segmentation setup code in kern/entry.S, - trace into it, and see if you were right. + if the mapping weren't in place? + Comment out the movl %eax, %cr0 in + kern/entry.S, + trace into it, + and see if you were right.