X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fvm.texi;h=8afc49c53d6f9a17665c6f3e22469fa89f8b3dfb;hb=1802b7b7b8d5e3d6754da9468e22942a8c29982b;hp=bc7fd46fa9e03719c47d763bb0c07b6045d489e0;hpb=3c7b982c3784e0f61993e1f64a89673aa4855840;p=pintos-anon diff --git a/doc/vm.texi b/doc/vm.texi index bc7fd46..8afc49c 100644 --- a/doc/vm.texi +++ b/doc/vm.texi @@ -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, -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 @@ -479,12 +480,11 @@ script, so the code you turn in must properly handle all cases. Implement stack growth. In project 2, the stack was a single page at the top of the user virtual address space, and programs were limited to that much stack. Now, if the stack grows past its current size, -allocate additional page as necessary. +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 -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 @@ -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. +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. -(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 @@ -580,9 +595,15 @@ Here's a summary of our reference solution, produced by the @command{diffstat} program. The final row gives total lines inserted and deleted; a changed line counts as both an insertion and a deletion. -This summary is relative to the Pintos base code, but we started from -the reference solution to project 2. @xref{Project 2 FAQ}, for the -summary of project 2. +This summary is relative to the Pintos base code, but the reference +solution for project 3 starts from the reference solution to project 2. +@xref{Project 2 FAQ}, for the summary of project 2. + +The reference solution represents just one possible solution. Many +other solutions are also possible and many of those differ greatly from +the reference solution. Some excellent solutions may not modify all the +files modified by the reference solution, and some may modify files not +modified by the reference solution. @verbatim Makefile.build | 4 @@ -605,7 +626,7 @@ summary of project 2. 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. @@ -649,7 +670,7 @@ kernel functions need to obtain memory. You can layer some other allocator on top of @func{palloc_get_page} if you like, but it should be the underlying mechanism. -Also, you can use the @option{-u} option to @command{pintos} to limit +Also, you can use the @option{-ul} option to @command{pintos} to limit the size of the user pool, which makes it easy to test your VM implementation with various user memory sizes. @@ -692,7 +713,7 @@ with the file mapped into your address space, you can directly address it like so: @example -write (addr, 64, STDOUT_FILENO); +write (STDOUT_FILENO, addr, 64); @end example Similarly, if you wanted to replace the first byte of the file,