lecture 12 notes
authorKyle Spaans <kspaans@student.math.uwaterloo.ca>
Tue, 16 Jun 2009 21:09:07 +0000 (17:09 -0400)
committerKyle Spaans <kspaans@student.math.uwaterloo.ca>
Tue, 16 Jun 2009 21:09:07 +0000 (17:09 -0400)
lec12-0616.tex [new file with mode: 0644]

diff --git a/lec12-0616.tex b/lec12-0616.tex
new file mode 100644 (file)
index 0000000..3333e88
--- /dev/null
@@ -0,0 +1,82 @@
+\documentclass{article}
+\usepackage{fullpage}
+\usepackage{amsmath}
+\author{Kyle Spaans}
+\date{June 16, 2009}
+\title{Operating Systems Lecture Notes}
+\begin{document}
+\maketitle 
+
+\section*{Lecture 12 -- Address Space}
+Midterms were handed back today. Models solutions are on the course website.
+The A2 tutorials will be held this afternoon.
+
+A quick address translation exercise: given the size and location of the code
+and data segments of an address space (vbase1=\texttt{0x400000}, 
+pbase1=\texttt{0x10000}, npages1=\texttt{0x2B}, vbase2=\texttt{0x10000000}, 
+vbase2=\texttt{0x40000}, npages2=\texttt{0x200}) and recalling that the page
+size is $2^{12}$ bytes (4KB, \texttt{0x1000}) what is the page number and frame
+number when we get a TLB fault on this virtual address: \texttt{0x00411608}?
+First, note that the address is valid, it falls within the code segment (vbase1,
+npages1). The offset is the 3 least significant hexits, \texttt{0x608}, meaning
+the page number can be found in \texttt{0x411}. Since \texttt{0x400000} maps to
+\texttt{0x10000} then \texttt{0x4110000} maps to \texttt{0x21000} meaning the
+frame number is \texttt{0x21}. We need to be able to do this for tests.
+
+\subsection*{Segmenting the Address Space}
+OSes, or \emph{OS161} at least treats the address space as 3 segments, code
+(aka text), data, and stack. If the MMU can't find the requested virtual
+address in the TLB, it causes a ``address exception'' trap. This lets the OS
+deal the fault by generating the necessary translation and placing it in the
+TLB before execution returns to the program that requested the address.
+
+\subsection*{Address Space for the Kernel}
+Where does the kernel live? It's a program too, so it needs some kind of
+address space. Consider sharing memory between two processes. Since they have
+seperate address spaces, the kernel needs to do something special. It could
+map parts of the two address spaces to the same frame of physical memory. The
+processes would need to know about this which is why memory sharing is usually
+requested by processes. Shared memory can also be used to save space. This is
+easy to do if, for example, multiple processes are executing the same program.
+Then the program's read-only, executable code can be shared by each process
+rather than needing to be replicated for each process (wasteful if the program
+is large, or if there is not very much physical memory to go around). Units of
+sharing can be pages or whole segments.
+
+Returning to where the kernel should go in memory, consider the
+\texttt{write()} system call which will get a pointer and two integers in its
+argument registers. We could put the kernel in a set physical memory area, and
+disable address translation while in priviledged mode. This is the oldschool
+way that OSes would do things. If this were the case, then to figure out the
+``buf'' argument to \texttt{write()}, the kernel would have to translate that
+virtual address, probably by looking in the process' page table (by hand).
+
+Alternatively, we could have the kernel in its own address space. This would
+keep it safe from user programs. But now in order to understand the ``buf''
+argument, it would have to do two translations. One to turn the virtual
+address (from the process' address space) into a physical one, then a second
+translation, turning the physical address into a virtual address in the
+kernel's address space.
+
+The more elegant solution, used in \emph{OS161}, Linux, and others, is to place
+the kernel in a certain part of the virtual address space of every process.
+This way, the kernel can use process' virtual address space (and the TLB
+implicitly) to figure out ``buf''. The kernel's memory is protected from reads
+or writes by the hardware, which will trap if the program tries to access
+memory that it isn't supposed to. The specific virtual addresses are
+\texttt{0x80000000} - \texttt{0xA0000000}, and these are always mapped by
+the hardware to physical addresses \texttt{0x00000000} and up (taking up the
+first 512MB of space). Since it is always mapped directly like this, entries
+need not be placed in the TLB.
+
+\subsection*{A2 \texttt{copyinout.c} Notes}
+These functions can be used to copy data from user space into kernel space.
+This is handy if the data needs to be copied anyway (e.g. into a special buffer
+for a device, like a hard drive), but they are also very nice because they
+gracefully handle error conditions. If the user tries to call \texttt{write()}
+and gives a value for ``buf'' that's not valid, or in kernel space, etc, then
+this should be caught, and an appropriate error returned from \texttt{write()}.
+The functions in \texttt{copyinout.c} will handle this for us. Remember,
+\texttt{write()} should not make the system panic if it's passed an invalid
+parameter.
+\end{document}