Update Intel architecture guide references to latest.
[pintos-anon] / doc / vm.texi
index 8ea6ee46b8c37b6897df3ddd365ed9428c731d1e..840e506a129586d9c2857f22a86a4325cdfafc01 100644 (file)
@@ -318,8 +318,9 @@ useful for this purpose (@pxref{Hash Table}).
 
 It is possible to do this translation without adding a new data
 structure, by modifying the code in @file{userprog/pagedir.c}.  However,
 
 It is possible to do this translation without adding a new data
 structure, by modifying the code in @file{userprog/pagedir.c}.  However,
-if you do that you'll need to carefully study and understand section 3.7
-in @bibref{IA32-v3}, and in practice it is probably easier to add a new
+if you do that you'll need to carefully study and understand section
+3.7, ``Page Translation Using 32-Bit Physical Addressing,'' in
+@bibref{IA32-v3a}, and in practice it is probably easier to add a new
 data structure.
 
 @item
 data structure.
 
 @item
@@ -483,8 +484,7 @@ allocate additional pages as necessary.
 
 Allocate additional pages only if they ``appear'' to be stack accesses.
 Devise a heuristic that attempts to distinguish stack accesses from
 
 Allocate additional pages only if they ``appear'' to be stack accesses.
 Devise a heuristic that attempts to distinguish stack accesses from
-other accesses.  You can retrieve the user program's current stack
-pointer from the @struct{intr_frame}'s @code{esp} member.
+other accesses.
 
 User programs are buggy if they write to the stack below the stack
 pointer, because typical real OSes may interrupt a process at any time
 
 User programs are buggy if they write to the stack below the stack
 pointer, because typical real OSes may interrupt a process at any time
@@ -500,9 +500,24 @@ not be restartable in a straightforward fashion.)  Similarly, the
 @code{PUSHA} instruction pushes 32 bytes at once, so it can fault 32
 bytes below the stack pointer.
 
 @code{PUSHA} instruction pushes 32 bytes at once, so it can fault 32
 bytes below the stack pointer.
 
+You will need to be able to obtain the current value of the user
+program's stack pointer.  Within a system call or a page fault generated
+by a user program, you can retrieve it from @code{esp} member of the
+@struct{intr_frame} passed to @func{syscall_handler} or
+@func{page_fault}, respectively.  If you verify user pointers before
+accessing them (@pxref{Accessing User Memory}), these are the only cases
+you need to handle.  On the other hand, if you depend on page faults to
+detect invalid memory access, you will need to handle another case,
+where a page fault occurs in the kernel.  Reading @code{esp} out of the
+@struct{intr_frame} passed to @func{page_fault} in that case will obtain
+the kernel stack pointer, not the user stack pointer.  You will need to
+arrange another way, e.g.@: by saving @code{esp} into @struct{thread} on
+the initial transition from user to kernel mode.
+
 You may impose some absolute limit on stack size, as do most OSes.
 You may impose some absolute limit on stack size, as do most OSes.
-(Some OSes make the limit user-adjustable, e.g.@: with the
-@command{ulimit} command on many Unix systems.)
+Some OSes make the limit user-adjustable, e.g.@: with the
+@command{ulimit} command on many Unix systems.  On many GNU/Linux systems,
+the default limit is 8 MB.
 
 The first stack page need not be allocated lazily.  You can initialize
 it with the command line arguments at load time, with no need to wait
 
 The first stack page need not be allocated lazily.  You can initialize
 it with the command line arguments at load time, with no need to wait
@@ -611,7 +626,7 @@ modified by the reference solution.
  17 files changed, 1532 insertions(+), 104 deletions(-)
 @end verbatim
 
  17 files changed, 1532 insertions(+), 104 deletions(-)
 @end verbatim
 
-@item Do we need a working HW 2 to implement HW 3?
+@item Do we need a working Project 2 to implement Project 3?
 
 Yes.
 
 
 Yes.