Cleanup
[barrelfish] / doc / 004-virtual_memory / VirtualMemory.tex
1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2 % Copyright (c) 2011, 2012, 2013, ETH Zurich.
3 % All rights reserved.
4 %
5 % This file is distributed under the terms in the attached LICENSE file.
6 % If you do not find this file, copies can be found by writing to:
7 % ETH Zurich D-INFK, CAB F.78, Universitaetstr. 6, CH-8092 Zurich,
8 % Attn: Systems Group.
9 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
10
11 \documentclass[a4paper,twoside]{report} % for a report (default)
12
13 \usepackage{bftn} % You need this
14
15 \title{Virtual Memory in Barrelfish}   % title of report
16 \author{Akhilesh Singhania, Simon Gerber}       % author
17 \tnnumber{004}  % give the number of the tech report
18 \tnkey{Virtual Memory} % Short title, will appear in footer
19
20 % \date{Month Year} % Not needed - will be taken from version history
21
22 \begin{document}
23 \maketitle
24
25 %
26 % Include version history first
27 %
28 \begin{versionhistory}
29 \vhEntry{2.0}{09.12.2013}{SG}{Updated with new kernel memory interface}
30 \vhEntry{1.0}{08.02.2010}{AS}{Initial version}
31 \end{versionhistory}
32
33 % \intro{Abstract}              % Insert abstract here
34 % \intro{Acknowledgements}      % Uncomment (if needed) for acknowledgements
35 % \tableofcontents              % Uncomment (if needed) for final draft
36 % \listoffigures                % Uncomment (if needed) for final draft
37 % \listoftables                 % Uncomment (if needed) for final draft
38
39 \chapter{Introduction}
40
41 This document describes the virtual memory system of Barrelfish.
42 It tries to describe the setup and the design decisions made in the construction of the system.
43
44 \chapter{Description}
45
46 The virtual memory system is made up of four user space components listed
47 below and utilizes the capability system to create hardware page tables.
48
49 \begin{itemize}
50 \item Vspace
51 \item Vregion
52 \item Memory Object
53 \item Pmap
54 \end{itemize}
55
56 Vspace, vregion, and memory object are designed to be architecture independent.
57 All architecture specific implementation for manipulating page tables is contained in pmaps.
58
59 The pmap code will invoke certain capability operations to create hardware
60 page tables that match the user space vspace layout.
61
62 Each are described in more detail below.
63
64 \section{Vspace}
65 A pagetable is represented by a vspace object.
66 The vspace object is associated with exactly one pmap object and a list of vregions.
67 By maintaining a list of vregions,
68 vspace also maintains a list of all virtual address regions that are currently mapped in.
69
70 To construct a new pagetable,
71 a new vspace is created and it is associated with an appropriate pmap.
72
73 Pagefaults in a dispatcher should be directed to it.
74 The vspace object looks up the appropriate vregion for the faulting address and passes the fault to it.
75
76 \section{Vregion}
77 A vregion represents a contiguous block of virtual address space.
78 There is only one vregion for a block of address space in a page table.
79 Therefore, it is associated with exactly one vspace and exactly one memory object.
80
81 The object also maintains a set of architecture independent mapping flags.
82
83 \section{Memory Object}
84 A memory object manages a block of memory of various types.
85 Multiple vregions can be mapped into the same memory object.
86
87 Currently, the two prevalent memory objects are anonymous type (maintains a list of frames)
88 and as an optimization a single frame memory object.
89
90 Further, a memory object of type pinned is implemented.
91 Its functionality is near identical to the anonymous type
92 except that it does not track the frames.
93 This object is used to back memory required for metadata in the library.
94 It can only be mapped into a single vregion.
95
96 Another memory object is of type single frame which maps portions of the frame lazily.
97 This supports users that have a large frame that need not be mapped in its entirety.
98
99 \section{Pmap}
100 Pmap performs actual page table mappings.
101 This is the only architecture specific portion of the virtual memory system.
102
103 The size of a virtual address space is architecture dependent and established at compile time.
104 It is a property of the pmap.
105
106 Pmap is also responsible for deciding where a given memory object can be mapped.
107 Since the vspace maintains the list of currently occupied regions, pmap may have to consult it.
108
109 For MMUs that do not offer address translation,
110 pmap can simply inspect the memory object and return the address of the physical object itself.
111
112 \section{Capability invocations}
113
114 The pmap calls into the kernel using invocations on the page table capability
115 types (namely \verb|VNode_Map|, \verb|VNode_Unmap|, and
116 \verb|VNode_ModifyFlags|).  These invocations are implemented in an
117 architecture specific manner and are used to install, remove and modify
118 mappings respectively.
119
120 In order for this system to make it possible to remove mappings when the
121 underlying Frame capability is deleted each copy of a Frame capability knows
122 if and where it is mapped in a page table.  This has a couple consequences,
123 the most important one of these is that each copy of a Frame capability can
124 only be mapped once (i.e. each copy of a Frame can only be supplied as an
125 argument to \verb|VNode_Map| once unless there is an unmap invocation
126 inbetween).
127
128 On the other hand this issue has been minimized as it's possible to create
129 multiple hardware page table entries using only one invocation.  Specifically
130 it's possible to create a contiguous region of page table entries inside one
131 page table frame using one invocation.
132
133 \chapter{Known issues}
134 Detail some of the known issues with the system.
135
136 \section{Mapping the same memory object in different pagetables}
137 Currently, a shared frame between two or more pagetables is
138 represented by different memory objects with no association.
139 The shared frame should be represented by the same object so that changes in one are reflected on the other.
140 We envision that this maybe in the form of a single object
141 with multiple instances which communicate via messages/sharing.
142 Changes in one will be communicated to the others and operations will fail if not consistent.
143
144 \section{Shared page table between domains}
145 Actual mappings are visible between domains
146 but the userlevel structures are not updated to reflect the mapping.
147
148 \section{Memory object of type anonymous}
149 Anonymous type memory objects can only be used if the MMU supports address translation.
150 The reason is because the object reserves virtual address space when initialized
151 and during initialization not all frames have been allocated yet.
152 Currently, the memory object is used in the heap, slot allocator, spawning domains, pci domain, and vmkit domain.
153
154 \section{Portability}
155 Libbarrelfish initialization path will require knowledge of the architecture type
156 so as to initialize the right type of pmap object.
157
158 A domain can only construct pagetables for an MMU of the same type as the one it is using.
159
160 Architecture of one type cannot compile pmaps for another architecture.
161
162 \section{Page faults}
163 Currently, we do not handle page faults in user space.
164 Although the API is generally designed to allow for demand paging, this is not yet possible.
165 Therefore, the user of the library explicitly uses the pagefault API to create mappings.
166 This is hidden behind wrapper functions and most users of the library are shielded from this.
167
168 \end{document}