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.