-
Notifications
You must be signed in to change notification settings - Fork 1
/
answers-lab2.txt
103 lines (76 loc) · 4.65 KB
/
answers-lab2.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
CSE P 551: Operating Systems (Autumn 2014)
Jeff Weiner ([email protected])
Myles Jordan ([email protected])
October 15th, 2014
What we did to solve the exercises:
It’s not clear what this question is really asking of us, but in general we
read the lab writeup, tried to understand the relevant details of JOS, read the
code and hints, then wrote and debugged code until it worked. Jeff took
exercises 1 and 5, and Myles took exercise 4, and we both collaborated on the
six questions/answers below.
Challenges:
* Implemented a kernel monitor function 'dumptable', which displays all mapped
entries in a specified page table (and defaults to the page directory if no
table is specified). The physical memory address is displayed, but the
monitor function expects a virtual address, so +KERNBASE (0xF0000000) as
needed. This helped us complete Question #2, among other things.
Questions & Answers:
1. Assuming that the following JOS kernel code is correct, what type should
variable x have, uintptr_t or physaddr_t?
mystery_t x;
char* value = return_a_pointer();
*value = 10;
x = (mystery_t) value;
uintptr_t. Given that we set the memory at *value to the value 10, and the MMU
always operates on virtual addresses, mystery_t must be virtual too.
2. What entries (rows) in the page directory have been filled in at this point?
What addresses they map and where do they point? In other words, fill out
this table as much as possible:
Entry Base VAddr Points to (logically)
===== ========== =====================
1023 0xFFC00000 Reflection of all physical memory (252-256MB)
1022 0xFF800000 Reflection of all physical memory (248-252MB)
961...1021 Reflection of all physical memory (4-248MB)
960 0xF0000000 Reflection of all physical memory (0-4MB)
959 0xEFC00000 Kernel Stack
957 0xEF400000 Page directory itself, inserted as a page table
956 0xEF000000 UPAGES, the shared kernel-user data area
(all other entries are invalid and/or not yet mapped)
3. (From Lecture 3) We have placed the kernel and user environment in the same
address space. Why will user programs not be able to read or write the
kernel's memory? What specific mechanisms protect the kernel memory?
The page table has a flag to identify whether a given page is accessible to
user-mode code or not (PTE_U), and without this flag on a given page for the
virtual address in question, the MMU will issue a page fault when resolving
that virtual address for a user-mode process.
4. What is the maximum amount of physical memory that this operating system
can support? Why?
256MB. JOS defines the virtual address range 0xF0000000-0xFFFFFFFF to be the
view of physical memory, and this range is only large enough to hold 256MB.
Given JOS’ self-imposed reliance on this view (most notably with the PADDR and
KADDR macros), 256MB is the largest amount of physical memory that JOS can
effectively utilize, despite having a much larger address space.
5. How much space overhead is there for managing memory, if we actually had
the maximum amount of physical memory? How is this overhead broken down?
If we have the full 256MB of ram, then there would need to be 256MB / 4KB per
page = 64,000 pages, hence 64k page table entries at 4B each = 256KB, plus
another 4KB for the page directory. However, each page is mapped twice (once
into kernel space and once into user space), so it would actually need
256KB*2 = 512KB for page tables + 4KB for the page directory.
To be clear, however, even a small amount of physical ram can be mapped to fill
the virtual address space, so in a pathological case, memory management could
potentially take up 4GB / 4KB = 1M pages, requiring 4MB of ram for the page
tables + 4Kb for the page directory.
6. Revisit the page table setup in kern/entry.S and kern/entrypgdir.c.
Immediately after we turn on paging, EIP is still a low number (a little
over 1MB). At what point do we transition to running at an EIP above
KERNBASE? What makes it possible for us to continue executing at a low EIP
between when we enable paging and when we begin running at an EIP above
KERNBASE? Why is this transition necessary?
We transition to running EIP above KERNBASE at line 68 of entry.S (jmp *%eax),
and the main reason that this functions correctly is because of the page table
described in entrypgdir.c which is installed earlier, after which both
addresses (low memory and high memory) of the executing code are mapped to the
same physical memory. This transition is necessary because that is where
we’ve arbitrarily decided the kernel should sit, and it enables us to
eventually unmap the low memory instance of the kernel.