ia64/xen-unstable

changeset 2780:9b7a35c0e304

bitkeeper revision 1.1159.1.309 (418284a5GxYb-BJtMJAP97pxfWMgww)

Merge freefall.cl.cam.ac.uk:/auto/groups/xeno/BK/xeno.bk
into freefall.cl.cam.ac.uk:/local/scratch/kaf24/xen-balloon-list.bk
author kaf24@freefall.cl.cam.ac.uk
date Fri Oct 29 17:57:57 2004 +0000 (2004-10-29)
parents 0f8ac790fa96 5bfc4a20f04d
children 10ffc8273164
files .rootkeys BitKeeper/etc/ignore docs/figs/xenserver.obj docs/src/interface.tex docs/src/user.tex
line diff
     1.1 --- a/.rootkeys	Fri Oct 29 17:26:59 2004 +0000
     1.2 +++ b/.rootkeys	Fri Oct 29 17:57:57 2004 +0000
     1.3 @@ -8,6 +8,7 @@ 3f5ef5a24IaQasQE2tyMxrfxskMmvw README
     1.4  3f69d8abYB1vMyD_QVDvzxy5Zscf1A TODO
     1.5  3f9e7d53iC47UnlfORp9iC1vai6kWw docs/Makefile
     1.6  3f9e7d60PWZJeVh5xdnk0nLUdxlqEA docs/figs/xenlogo.eps
     1.7 +418273f3YZUyGIrNbERVAPFeOd9gww docs/figs/xenserver.obj
     1.8  4022a73cgxX1ryj1HgS-IwwB6NUi2A docs/misc/XenDebugger-HOWTO
     1.9  412f4bd9sm5mCQ8BkrgKcAKZGadq7Q docs/misc/blkif-drivers-explained.txt
    1.10  40d6ccbfKKBq8jE0ula4eHEzBiQuDA docs/misc/xen_config.html
     2.1 --- a/BitKeeper/etc/ignore	Fri Oct 29 17:26:59 2004 +0000
     2.2 +++ b/BitKeeper/etc/ignore	Fri Oct 29 17:57:57 2004 +0000
     2.3 @@ -78,3 +78,4 @@ docs/xend/internals.pl
     2.4  docs/xend/labels.pl
     2.5  docs/xend/xend.css
     2.6  docs/xend/xend.html
     2.7 +docs/figs/xenserver.eps
     3.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.2 +++ b/docs/figs/xenserver.obj	Fri Oct 29 17:57:57 2004 +0000
     3.3 @@ -0,0 +1,312 @@
     3.4 +%TGIF 4.1.8
     3.5 +state(0,37,100.000,0,108,0,4,1,16,2,2,2,0,1,2,1,1,'Helvetica-Oblique',2,80640,0,8,1,5,-4,0,1,1,0,16,1,0,1,1,1,1,1088,1408,0,0,2880,0).
     3.6 +%
     3.7 +% @(#)$Header$
     3.8 +% %W%
     3.9 +%
    3.10 +unit("1 pixel/pixel").
    3.11 +color_info(28,65535,0,[
    3.12 +	"black", 0, 0, 0, 0, 0, 0, 1,
    3.13 +	"gray10", 6682, 6682, 6682, 6682, 6682, 6682, 1,
    3.14 +	"gray20", 13107, 13107, 13107, 13107, 13107, 13107, 1,
    3.15 +	"gray30", 19789, 19789, 19789, 19789, 19789, 19789, 1,
    3.16 +	"gray40", 26214, 26214, 26214, 26214, 26214, 26214, 1,
    3.17 +	"gray50", 32639, 32639, 32639, 32639, 32639, 32639, 1,
    3.18 +	"gray60", 39321, 39321, 39321, 39321, 39321, 39321, 1,
    3.19 +	"gray70", 46003, 46003, 46003, 46003, 46003, 46003, 1,
    3.20 +	"gray80", 52428, 52428, 52428, 52428, 52428, 52428, 1,
    3.21 +	"gray90", 58853, 58853, 58853, 58853, 58853, 58853, 1,
    3.22 +	"white", 65535, 65535, 65535, 65535, 65535, 65535, 1,
    3.23 +	"red", 65535, 0, 0, 65535, 0, 0, 1,
    3.24 +	"orange", 65535, 42405, 0, 65535, 42405, 0, 1,
    3.25 +	"yellow", 65535, 65535, 0, 65535, 65535, 0, 1,
    3.26 +	"green", 0, 65535, 0, 0, 65535, 0, 1,
    3.27 +	"blue", 0, 0, 65535, 0, 0, 65535, 1,
    3.28 +	"blue4", 0, 0, 35723, 0, 0, 35723, 1,
    3.29 +	"violet", 61166, 33410, 61166, 61166, 33410, 61166, 1,
    3.30 +	"magenta", 65535, 0, 65535, 65535, 0, 65535, 1,
    3.31 +	"cyan", 0, 65535, 65535, 0, 65535, 65535, 1,
    3.32 +	"wheat", 62965, 57054, 46003, 62965, 57054, 46003, 1,
    3.33 +	"wheat3", 52685, 47802, 38550, 52685, 47802, 38550, 1,
    3.34 +	"wheat4", 35723, 32382, 26214, 35723, 32382, 26214, 1,
    3.35 +	"pink", 65535, 49344, 52171, 65535, 49344, 52171, 1,
    3.36 +	"palegreen", 39064, 64507, 39064, 39064, 64507, 39064, 1,
    3.37 +	"skyblue", 34695, 52942, 60395, 34695, 52942, 60395, 1,
    3.38 +	"CadetBlue", 24415, 40606, 41120, 24415, 40606, 41120, 1,
    3.39 +	"DarkSlateGray", 12079, 20303, 20303, 12079, 20303, 20303, 1
    3.40 +]).
    3.41 +script_frac("0.6").
    3.42 +fg_bg_colors('blue4','gray90').
    3.43 +page(1,"",1,'').
    3.44 +group([
    3.45 +rcbox('gray90','',375,225,440,435,1,2,1,8,16,69683,0,0,0,0,'2',0,[
    3.46 +]),
    3.47 +rcbox('gray20','',375,225,440,435,0,2,1,8,16,69684,0,0,0,0,'2',0,[
    3.48 +])
    3.49 +],
    3.50 +69682,0,0,[
    3.51 +]).
    3.52 +group([
    3.53 +rcbox('gray90','',450,225,515,435,1,2,1,8,16,69623,0,0,0,0,'2',0,[
    3.54 +]),
    3.55 +rcbox('gray20','',450,225,515,435,0,2,1,8,16,69624,0,0,0,0,'2',0,[
    3.56 +])
    3.57 +],
    3.58 +69622,0,0,[
    3.59 +]).
    3.60 +group([
    3.61 +rcbox('gray90','',525,225,590,435,1,2,1,8,16,69119,0,0,0,0,'2',0,[
    3.62 +]),
    3.63 +rcbox('gray20','',525,225,590,435,0,2,1,8,16,69120,0,0,0,0,'2',0,[
    3.64 +])
    3.65 +],
    3.66 +69366,0,0,[
    3.67 +]).
    3.68 +box('gray40','',227,457,607,502,1,2,1,69020,0,0,0,0,0,'2',0,[
    3.69 +]).
    3.70 +box('gray40','',235,335,340,435,1,2,1,69017,0,0,0,0,0,'2',0,[
    3.71 +]).
    3.72 +box('gray40','',235,230,340,330,1,2,1,69001,0,0,0,0,0,'2',0,[
    3.73 +]).
    3.74 +box('gray80','',230,330,335,430,1,2,1,68660,0,0,0,0,0,'2',0,[
    3.75 +]).
    3.76 +box('gray80','',230,225,335,325,1,2,1,68663,0,0,0,0,0,'2',0,[
    3.77 +]).
    3.78 +box('gray70','',222,452,602,497,1,2,1,68416,0,0,0,0,0,'2',0,[
    3.79 +]).
    3.80 +text('black',621,451,3,1,1,14,55,68422,18,5,0,-7,0,0,2,14,55,-1,2,"",0,0,0,0,469,'',[
    3.81 +minilines(14,55,-1,2,1,-7,0,[
    3.82 +mini_line(12,18,5,-1,2,0,[
    3.83 +str_block(0,12,18,5,-1,2,0,0,0,[
    3.84 +str_seg('black','Helvetica-BoldOblique',3,115200,12,18,5,-1,2,0,0,0,0,0,
    3.85 +	"X")])
    3.86 +]),
    3.87 +mini_line(12,18,5,0,1,0,[
    3.88 +str_block(0,12,18,5,0,1,0,0,0,[
    3.89 +str_seg('black','Helvetica-BoldOblique',3,115200,12,18,5,0,1,0,0,0,0,0,
    3.90 +	"E")])
    3.91 +]),
    3.92 +mini_line(14,18,5,0,1,0,[
    3.93 +str_block(0,14,18,5,0,1,0,0,0,[
    3.94 +str_seg('black','Helvetica-BoldOblique',3,115200,14,18,5,0,1,0,0,0,0,0,
    3.95 +	"N")])
    3.96 +])
    3.97 +])]).
    3.98 +text('black',282,244,3,1,1,99,60,68643,16,4,0,0,0,0,2,99,60,-1,0,"",0,0,0,0,260,'',[
    3.99 +minilines(99,60,-1,0,1,0,0,[
   3.100 +mini_line(98,16,4,0,0,0,[
   3.101 +str_block(0,98,16,4,0,-4,0,0,0,[
   3.102 +str_seg('black','Helvetica-BoldOblique',3,97920,98,16,4,0,-4,0,0,0,0,0,
   3.103 +	"Control and ")])
   3.104 +]),
   3.105 +mini_line(99,16,4,-1,0,0,[
   3.106 +str_block(0,99,16,4,-1,0,0,0,0,[
   3.107 +str_seg('black','Helvetica-BoldOblique',3,97920,99,16,4,-1,0,0,0,0,0,0,
   3.108 +	"Management")])
   3.109 +]),
   3.110 +mini_line(69,16,4,0,0,0,[
   3.111 +str_block(0,69,16,4,0,-1,0,0,0,[
   3.112 +str_seg('black','Helvetica-BoldOblique',3,97920,69,16,4,0,-1,0,0,0,0,0,
   3.113 +	"Software")])
   3.114 +])
   3.115 +])]).
   3.116 +text('black',280,349,2,1,1,85,42,68748,18,5,0,-4,0,0,2,85,42,0,1,"",0,0,0,0,367,'',[
   3.117 +minilines(85,42,0,1,1,-4,0,[
   3.118 +mini_line(85,18,5,0,1,0,[
   3.119 +str_block(0,85,18,5,0,1,0,0,0,[
   3.120 +str_seg('black','Helvetica-BoldOblique',3,115200,85,18,5,0,1,0,0,0,0,0,
   3.121 +	"Privileged")])
   3.122 +]),
   3.123 +mini_line(79,18,5,0,0,0,[
   3.124 +str_block(0,79,18,5,0,0,0,0,0,[
   3.125 +str_seg('black','Helvetica-BoldOblique',3,115200,79,18,5,0,0,0,0,0,0,0,
   3.126 +	"GuestOS")])
   3.127 +])
   3.128 +])]).
   3.129 +text('black',280,393,1,1,1,74,17,68749,14,3,0,-4,0,0,2,74,17,0,0,"",0,0,0,0,407,'',[
   3.130 +minilines(74,17,0,0,1,-4,0,[
   3.131 +mini_line(74,14,3,0,0,0,[
   3.132 +str_block(0,74,14,3,0,0,0,0,0,[
   3.133 +str_seg('black','Helvetica-BoldOblique',3,80640,74,14,3,0,0,0,0,0,0,0,
   3.134 +	"(XenLinux)")])
   3.135 +])
   3.136 +])]).
   3.137 +box('gray80','',236,459,351,489,1,2,1,68474,0,0,0,0,0,'2',0,[
   3.138 +]).
   3.139 +text('black',291,465,1,1,1,92,17,68470,14,3,0,-4,0,0,2,92,17,0,3,"",0,0,0,0,479,'',[
   3.140 +minilines(92,17,0,3,1,-4,0,[
   3.141 +mini_line(92,14,3,0,3,0,[
   3.142 +str_block(0,92,14,3,0,3,0,0,0,[
   3.143 +str_seg('black','Helvetica-BoldOblique',3,80640,92,14,3,0,3,0,0,0,0,0,
   3.144 +	"VM control i/f")])
   3.145 +])
   3.146 +])]).
   3.147 +box('gray80','',396,459,586,489,1,2,1,68895,0,0,0,0,0,'2',0,[
   3.148 +]).
   3.149 +text('black',496,465,1,1,1,143,17,68896,14,3,0,-4,0,0,2,143,17,0,1,"",0,0,0,0,479,'',[
   3.150 +minilines(143,17,0,1,1,-4,0,[
   3.151 +mini_line(143,14,3,0,1,0,[
   3.152 +str_block(0,143,14,3,0,1,0,0,0,[
   3.153 +str_seg('black','Helvetica-BoldOblique',3,80640,143,14,3,0,1,0,0,0,0,0,
   3.154 +	"Virtualized Hardware")])
   3.155 +])
   3.156 +])]).
   3.157 +poly('black','',2,[
   3.158 +	355,473,395,473],1,4,1,68913,0,2,0,0,0,0,0,'4',0,0,
   3.159 +    "0","",[
   3.160 +    0,14,6,0,'14','6','0'],[0,14,6,0,'14','6','0'],[
   3.161 +]).
   3.162 +poly('black','',2,[
   3.163 +	280,423,280,453],1,4,1,68941,0,2,0,0,0,0,0,'4',0,0,
   3.164 +    "0","",[
   3.165 +    0,14,6,0,'14','6','0'],[0,14,6,0,'14','6','0'],[
   3.166 +]).
   3.167 +poly('black','',2,[
   3.168 +	255,313,255,343],1,2,1,68983,0,2,0,0,0,0,0,'2',0,0,
   3.169 +    "0","",[
   3.170 +    0,10,4,0,'10','4','0'],[0,10,4,0,'10','4','0'],[
   3.171 +]).
   3.172 +poly('black','',2,[
   3.173 +	305,313,305,343],1,2,1,68984,0,2,0,0,0,0,0,'2',0,0,
   3.174 +    "0","",[
   3.175 +    0,10,4,0,'10','4','0'],[0,10,4,0,'10','4','0'],[
   3.176 +]).
   3.177 +poly('black','',2,[
   3.178 +	280,313,280,343],1,2,1,68989,0,2,0,0,0,0,0,'2',0,0,
   3.179 +    "0","",[
   3.180 +    0,10,4,0,'10','4','0'],[0,10,4,0,'10','4','0'],[
   3.181 +]).
   3.182 +box('gray70','',284,520,609,555,1,2,1,68490,0,0,0,0,0,'2',0,[
   3.183 +]).
   3.184 +text('black',444,527,1,1,1,276,23,68493,18,5,0,-8,0,0,2,276,23,0,0,"",0,0,0,0,545,'',[
   3.185 +minilines(276,23,0,0,1,-8,0,[
   3.186 +mini_line(276,18,5,0,0,0,[
   3.187 +str_block(0,276,18,5,0,-1,0,0,0,[
   3.188 +str_seg('black','Helvetica-BoldOblique',3,115200,276,18,5,0,-1,0,0,0,0,0,
   3.189 +	"H/W (SMP x86, mem, net, block)")])
   3.190 +])
   3.191 +])]).
   3.192 +poly('black','',2,[
   3.193 +	445,483,445,518],3,3,1,68528,0,2,0,0,0,0,0,'3',0,0,
   3.194 +    "0","",[
   3.195 +    0,12,5,0,'12','5','0'],[0,12,5,0,'12','5','0'],[
   3.196 +]).
   3.197 +poly('black','',2,[
   3.198 +	500,483,500,518],3,3,1,68529,0,2,0,0,0,0,0,'3',0,0,
   3.199 +    "0","",[
   3.200 +    0,12,5,0,'12','5','0'],[0,12,5,0,'12','5','0'],[
   3.201 +]).
   3.202 +poly('black','',2,[
   3.203 +	555,483,555,518],3,3,1,68530,0,2,0,0,0,0,0,'3',0,0,
   3.204 +    "0","",[
   3.205 +    0,12,5,0,'12','5','0'],[0,12,5,0,'12','5','0'],[
   3.206 +]).
   3.207 +text('black',405,254,2,1,1,34,36,68698,16,4,0,-4,0,0,2,34,36,0,1,"",0,0,0,0,270,'',[
   3.208 +minilines(34,36,0,1,1,-4,0,[
   3.209 +mini_line(34,16,4,0,1,0,[
   3.210 +str_block(0,34,16,4,0,1,0,0,0,[
   3.211 +str_seg('blue4','Helvetica-Oblique',2,97920,34,16,4,0,1,0,0,0,0,0,
   3.212 +	"User")])
   3.213 +]),
   3.214 +mini_line(32,16,4,0,1,0,[
   3.215 +str_block(0,32,16,4,0,1,0,0,0,[
   3.216 +str_seg('blue4','Helvetica-Oblique',2,97920,32,16,4,0,1,0,0,0,0,0,
   3.217 +	"S/W")])
   3.218 +])
   3.219 +])]).
   3.220 +text('black',405,354,3,1,1,44,52,69100,16,4,0,-4,0,0,2,44,52,0,1,"",0,0,0,0,370,'',[
   3.221 +minilines(44,52,0,1,1,-4,0,[
   3.222 +mini_line(34,16,4,0,1,0,[
   3.223 +str_block(0,34,16,4,0,1,0,0,0,[
   3.224 +str_seg('blue4','Helvetica-Oblique',2,97920,34,16,4,0,1,0,0,0,0,0,
   3.225 +	"User")])
   3.226 +]),
   3.227 +mini_line(44,16,4,0,0,0,[
   3.228 +str_block(0,44,16,4,0,0,0,0,0,[
   3.229 +str_seg('blue4','Helvetica-Oblique',2,97920,44,16,4,0,0,0,0,0,0,0,
   3.230 +	"Guest")])
   3.231 +]),
   3.232 +mini_line(24,16,4,0,0,0,[
   3.233 +str_block(0,24,16,4,0,0,0,0,0,[
   3.234 +str_seg('blue4','Helvetica-Oblique',2,97920,24,16,4,0,0,0,0,0,0,0,
   3.235 +	"OS")])
   3.236 +])
   3.237 +])]).
   3.238 +text('black',480,254,2,1,1,34,36,69114,16,4,0,-4,0,0,2,34,36,0,1,"",0,0,0,0,270,'',[
   3.239 +minilines(34,36,0,1,1,-4,0,[
   3.240 +mini_line(34,16,4,0,1,0,[
   3.241 +str_block(0,34,16,4,0,1,0,0,0,[
   3.242 +str_seg('blue4','Helvetica-Oblique',2,97920,34,16,4,0,1,0,0,0,0,0,
   3.243 +	"User")])
   3.244 +]),
   3.245 +mini_line(32,16,4,0,1,0,[
   3.246 +str_block(0,32,16,4,0,1,0,0,0,[
   3.247 +str_seg('blue4','Helvetica-Oblique',2,97920,32,16,4,0,1,0,0,0,0,0,
   3.248 +	"S/W")])
   3.249 +])
   3.250 +])]).
   3.251 +text('black',480,354,3,1,1,44,52,69115,16,4,0,-4,0,0,2,44,52,0,1,"",0,0,0,0,370,'',[
   3.252 +minilines(44,52,0,1,1,-4,0,[
   3.253 +mini_line(34,16,4,0,1,0,[
   3.254 +str_block(0,34,16,4,0,1,0,0,0,[
   3.255 +str_seg('blue4','Helvetica-Oblique',2,97920,34,16,4,0,1,0,0,0,0,0,
   3.256 +	"User")])
   3.257 +]),
   3.258 +mini_line(44,16,4,0,0,0,[
   3.259 +str_block(0,44,16,4,0,0,0,0,0,[
   3.260 +str_seg('blue4','Helvetica-Oblique',2,97920,44,16,4,0,0,0,0,0,0,0,
   3.261 +	"Guest")])
   3.262 +]),
   3.263 +mini_line(24,16,4,0,0,0,[
   3.264 +str_block(0,24,16,4,0,0,0,0,0,[
   3.265 +str_seg('blue4','Helvetica-Oblique',2,97920,24,16,4,0,0,0,0,0,0,0,
   3.266 +	"OS")])
   3.267 +])
   3.268 +])]).
   3.269 +text('black',555,254,2,1,1,34,36,69116,16,4,0,-4,0,0,2,34,36,0,1,"",0,0,0,0,270,'',[
   3.270 +minilines(34,36,0,1,1,-4,0,[
   3.271 +mini_line(34,16,4,0,1,0,[
   3.272 +str_block(0,34,16,4,0,1,0,0,0,[
   3.273 +str_seg('blue4','Helvetica-Oblique',2,97920,34,16,4,0,1,0,0,0,0,0,
   3.274 +	"User")])
   3.275 +]),
   3.276 +mini_line(32,16,4,0,1,0,[
   3.277 +str_block(0,32,16,4,0,1,0,0,0,[
   3.278 +str_seg('blue4','Helvetica-Oblique',2,97920,32,16,4,0,1,0,0,0,0,0,
   3.279 +	"S/W")])
   3.280 +])
   3.281 +])]).
   3.282 +text('black',555,354,3,1,1,44,52,69117,16,4,0,-4,0,0,2,44,52,0,1,"",0,0,0,0,370,'',[
   3.283 +minilines(44,52,0,1,1,-4,0,[
   3.284 +mini_line(34,16,4,0,1,0,[
   3.285 +str_block(0,34,16,4,0,1,0,0,0,[
   3.286 +str_seg('blue4','Helvetica-Oblique',2,97920,34,16,4,0,1,0,0,0,0,0,
   3.287 +	"User")])
   3.288 +]),
   3.289 +mini_line(44,16,4,0,0,0,[
   3.290 +str_block(0,44,16,4,0,0,0,0,0,[
   3.291 +str_seg('blue4','Helvetica-Oblique',2,97920,44,16,4,0,0,0,0,0,0,0,
   3.292 +	"Guest")])
   3.293 +]),
   3.294 +mini_line(24,16,4,0,0,0,[
   3.295 +str_block(0,24,16,4,0,0,0,0,0,[
   3.296 +str_seg('blue4','Helvetica-Oblique',2,97920,24,16,4,0,0,0,0,0,0,0,
   3.297 +	"OS")])
   3.298 +])
   3.299 +])]).
   3.300 +text('black',282,201,1,1,1,116,17,69753,14,3,2,-4,0,0,2,116,17,0,2,"",0,0,0,0,215,'',[
   3.301 +minilines(116,17,0,2,1,-4,0,[
   3.302 +mini_line(116,14,3,0,2,0,[
   3.303 +str_block(0,116,14,3,0,2,0,0,0,[
   3.304 +str_seg('blue4','Helvetica-BoldOblique',3,80640,116,14,3,0,2,0,0,0,0,0,
   3.305 +	"Management VM")])
   3.306 +])
   3.307 +])]).
   3.308 +text('black',480,201,1,1,1,146,17,69770,14,3,2,-4,0,0,2,146,17,0,0,"",0,0,0,0,215,'',[
   3.309 +minilines(146,17,0,0,1,-4,0,[
   3.310 +mini_line(146,14,3,0,0,0,[
   3.311 +str_block(0,146,14,3,0,0,0,0,0,[
   3.312 +str_seg('blue4','Helvetica-Oblique',2,80640,146,14,3,0,0,0,0,0,0,0,
   3.313 +	"User Virtual Machines")])
   3.314 +])
   3.315 +])]).
     4.1 --- a/docs/src/interface.tex	Fri Oct 29 17:26:59 2004 +0000
     4.2 +++ b/docs/src/interface.tex	Fri Oct 29 17:57:57 2004 +0000
     4.3 @@ -1,5 +1,6 @@
     4.4  \documentclass[11pt,twoside,final,openright]{xenstyle}
     4.5  \usepackage{a4,graphicx,setspace,times}
     4.6 +\usepackage{comment,parskip}
     4.7  \setstretch{1.15}
     4.8  
     4.9  \begin{document}
    4.10 @@ -16,12 +17,19 @@
    4.11  {\Huge \bf Interface manual} \\[4mm]
    4.12  {\huge Xen v2.0 for x86} \\[80mm]
    4.13  
    4.14 -{\Large Xen is Copyright (c) 2004, The Xen Team} \\[3mm]
    4.15 +{\Large Xen is Copyright (c) 2002-2004, The Xen Team} \\[3mm]
    4.16  {\Large University of Cambridge, UK} \\[20mm]
    4.17 -{\large Last updated on 11th March, 2004}
    4.18  \end{tabular}
    4.19 +\end{center}
    4.20 +
    4.21 +{\bf
    4.22 +DISCLAIMER: This documentation is currently under active development
    4.23 +and as such there may be mistakes and omissions --- watch out for
    4.24 +these and please report any you find to the developer's mailing list.
    4.25 +Contributions of material, suggestions and corrections are welcome.
    4.26 +}
    4.27 +
    4.28  \vfill
    4.29 -\end{center}
    4.30  \cleardoublepage
    4.31  
    4.32  % TABLE OF CONTENTS
    4.33 @@ -45,205 +53,218 @@
    4.34  \setstretch{1.15}
    4.35  
    4.36  \chapter{Introduction}
    4.37 -Xen allows the hardware resouces of a machine to be virtualized and
    4.38 -dynamically partitioned such as to allow multiple different 'guest'
    4.39 -operating system images to be run simultaneously.
    4.40  
    4.41 -Virtualizing the machine in this manner provides flexibility allowing
    4.42 -different users to choose their preferred operating system (Windows,
    4.43 -Linux, NetBSD, or a custom operating system).  Furthermore, Xen provides
    4.44 -secure partitioning between these 'domains', and enables better resource
    4.45 +Xen allows the hardware resources of a machine to be virtualized and
    4.46 +dynamically partitioned, allowing multiple different {\em guest}
    4.47 +operating system images to be run simultaneously.  Virtualizing the
    4.48 +machine in this manner provides considerable flexibility, for example
    4.49 +allowing different users to choose their preferred operating system
    4.50 +(e.g., Linux, NetBSD, or a custom operating system).  Furthermore, Xen
    4.51 +provides secure partitioning between virtual machines (known as
    4.52 +{\em domains} in Xen terminology), and enables better resource
    4.53  accounting and QoS isolation than can be achieved with a conventional
    4.54 -operating system.
    4.55 -
    4.56 -The hypervisor runs directly on server hardware and dynamically partitions
    4.57 -it between a number of {\it domains}, each of which hosts an instance
    4.58 -of a {\it guest operating system}.  The hypervisor provides just enough
    4.59 -abstraction of the machine to allow effective isolation and resource 
    4.60 -management between these domains.
    4.61 +operating system. 
    4.62  
    4.63 -Xen essentially takes a virtual machine approach as pioneered by IBM
    4.64 -VM/370.  However, unlike VM/370 or more recent efforts such as VMWare
    4.65 -and Virtual PC, Xen doesn not attempt to completely virtualize the
    4.66 -underlying hardware.  Instead parts of the hosted guest operating
    4.67 -systems are modified to work with the hypervisor; the operating system
    4.68 -is effectively ported to a new target architecture, typically
    4.69 -requiring changes in just the machine-dependent code.  The user-level
    4.70 -API is unchanged, thus existing binaries and operating system
    4.71 -distributions can work unmodified.
    4.72 +Xen essentially takes a `whole machine' virtualization approach as
    4.73 +pioneered by IBM VM/370.  However, unlike VM/370 or more recent
    4.74 +efforts such as VMWare and Virtual PC, Xen does not attempt to
    4.75 +completely virtualize the underlying hardware.  Instead parts of the
    4.76 +hosted guest operating systems are modified to work with the VMM; the
    4.77 +operating system is effectively ported to a new target architecture,
    4.78 +typically requiring changes in just the machine-dependent code.  The
    4.79 +user-level API is unchanged, and so existing binaries and operating
    4.80 +system distributions work without modification.
    4.81  
    4.82 -In addition to exporting virtualized instances of CPU, memory, network and
    4.83 -block devicees, Xen exposes a control interface to set how these resources
    4.84 -are shared between the running domains.  The control interface is privileged
    4.85 -and may only be accessed by one particular virtual machine: {\it domain0}.
    4.86 -This domain is a required part of any Xen-base server and runs the application
    4.87 -software that manages the control-plane aspects of the platform.  Running the
    4.88 -control software in {\it domain0}, distinct from the hypervisor itself, allows
    4.89 -the Xen framework to separate the notions of {\it mechanism} and {\it policy}
    4.90 -within the system.
    4.91 +In addition to exporting virtualized instances of CPU, memory, network
    4.92 +and block devices, Xen exposes a control interface to manage how these
    4.93 +resources are shared between the running domains. Access to the
    4.94 +control interface is restricted: it may only be used by one
    4.95 +specially-privileged VM, known as {\em domain-0}.  This domain is a
    4.96 +required part of any Xen-based server and runs the application software
    4.97 +that manages the control-plane aspects of the platform.  Running the
    4.98 +control software in {\it domain-0}, distinct from the hypervisor
    4.99 +itself, allows the Xen framework to separate the notions of 
   4.100 +mechanism and policy within the system.
   4.101  
   4.102  
   4.103 -\chapter{CPU state}
   4.104 +
   4.105 +\chapter{Virtual Architecture}
   4.106 +
   4.107 +On a Xen-based system, the hypervisor itself runs in {\it ring 0}.  It
   4.108 +has full access to the physical memory available in the system and is
   4.109 +responsible for allocating portions of it to the domains.  Guest
   4.110 +operating systems run in and use {\it rings 1}, {\it 2} and {\it 3} as
   4.111 +they see fit. Segmentation is used to prevent the guest OS from
   4.112 +accessing the portion of the address space that is reserved for
   4.113 +Xen. We expect most guest operating systems will use ring 1 for their
   4.114 +own operation and place applications in ring 3.
   4.115 +
   4.116 +In this chapter we consider the basic virtual architecture provided 
   4.117 +by Xen: the basic CPU state, exception and interrupt handling, and
   4.118 +time. Other aspects such as memory and device access are discussed 
   4.119 +in later chapters. 
   4.120 +
   4.121 +\section{CPU state}
   4.122  
   4.123  All privileged state must be handled by Xen.  The guest OS has no
   4.124  direct access to CR3 and is not permitted to update privileged bits in
   4.125 -EFLAGS.
   4.126 -
   4.127 -\chapter{Exceptions}
   4.128 -The IDT is virtualised by submitting a virtual 'trap
   4.129 -table' to Xen.  Most trap handlers are identical to native x86
   4.130 -handlers.  The page-fault handler is a noteable exception.
   4.131 +EFLAGS. Guest OSes use \emph{hypercalls} to invoke operations in Xen; 
   4.132 +these are analagous to system calls but occur from ring 1 to ring 0. 
   4.133  
   4.134 -\chapter{Interrupts and events}
   4.135 -Interrupts are virtualized by mapping them to events, which are delivered 
   4.136 -asynchronously to the target domain.  A guest OS can map these events onto
   4.137 -its standard interrupt dispatch mechanisms, such as a simple vectoring 
   4.138 -scheme.  Each physical interrupt source controlled by the hypervisor, including
   4.139 -network devices, disks, or the timer subsystem, is responsible for identifying
   4.140 -the target for an incoming interrupt and sending an event to that domain.
   4.141  
   4.142 -This demultiplexing mechanism also provides a device-specific mechanism for 
   4.143 -event coalescing or hold-off.  For example, a guest OS may request to only 
   4.144 -actually receive an event after {\it n} packets are queued ready for delivery
   4.145 -to it, {\it t} nanoseconds after the first packet arrived (which ever is true
   4.146 -first).  This allows latency and throughput requirements to be addressed on a
   4.147 -domain-specific basis.
   4.148 +\section{Exceptions}
   4.149  
   4.150 -\chapter{Time}
   4.151 -Guest operating systems need to be aware of the passage of real time and their
   4.152 -own ``virtual time'', i.e. the time they have been executing.  Furthermore, a
   4.153 -notion of time is required in the hypervisor itself for scheduling and the
   4.154 -activities that relate to it.  To this end the hypervisor provides for notions
   4.155 -of time:  cycle counter time, system time, wall clock time, domain virtual 
   4.156 -time.
   4.157 +The IDT is virtualised by submitting to Xen a table of trap handlers.
   4.158 +Most trap handlers are identical to native x86 handlers, although the
   4.159 +page-fault handler is somewhat different.
   4.160  
   4.161  
   4.162 -\section{Cycle counter time}
   4.163 -This provides the finest-grained, free-running time reference, with the
   4.164 -approximate frequency being publicly accessible.  The cycle counter time is
   4.165 +\section{Interrupts and events}
   4.166 +
   4.167 +Interrupts are virtualized by mapping them to events, which are
   4.168 +delivered asynchronously to the target domain.  A guest OS can map
   4.169 +these events onto its standard interrupt dispatch mechanisms.  Xen 
   4.170 +is responsible for determining the target domain that will handle 
   4.171 +each physical interrupt source. 
   4.172 +
   4.173 +
   4.174 +\section{Time}
   4.175 +
   4.176 +Guest operating systems need to be aware of the passage of both real
   4.177 +(or wallclock) time and their own `virtual time' (the time for
   4.178 +which they have been executing). Furthermore, Xen has a notion of 
   4.179 +time which is used for scheduling. The following notions of 
   4.180 +time are provided: 
   4.181 +
   4.182 +\begin{description}
   4.183 +\item[Cycle counter time.]
   4.184 +
   4.185 +This provides a fine-grained time reference.  The cycle counter time is
   4.186  used to accurately extrapolate the other time references.  On SMP machines
   4.187  it is currently assumed that the cycle counter time is synchronised between
   4.188  CPUs.  The current x86-based implementation achieves this within inter-CPU
   4.189  communication latencies.
   4.190  
   4.191 -\section{System time}
   4.192 -This is a 64-bit value containing the nanoseconds elapsed since boot
   4.193 -time.  Unlike cycle counter time, system time accurately reflects the
   4.194 -passage of real time, i.e.  it is adjusted several times a second for timer
   4.195 -drift.  This is done by running an NTP client in {\it domain0} on behalf of
   4.196 -the machine, feeding updates to the hypervisor.  Intermediate values can be
   4.197 -extrapolated using the cycle counter.
   4.198 +\item[System time.]
   4.199 +
   4.200 +This is a 64-bit counter which holds the number of nanoseconds that
   4.201 +have elapsed since system boot.
   4.202 +
   4.203  
   4.204 -\section{Wall clock time}
   4.205 -This is the actual ``time of day'' Unix style struct timeval (i.e. seconds and
   4.206 -microseconds since 1 January 1970, adjusted by leap seconds etc.).  Again, an 
   4.207 -NTP client hosted by {\it domain0} can help maintain this value.  To guest 
   4.208 -operating systems this value will be reported instead of the hardware RTC
   4.209 -clock value and they can use the system time and cycle counter times to start
   4.210 -and remain perfectly in time.
   4.211 +\item[Wall clock time.]
   4.212 +
   4.213 +This is the time of day in a Unix-style {\tt struct timeval} (seconds
   4.214 +and microseconds since 1 January 1970, adjusted by leap seconds).  An
   4.215 +NTP client hosted by {\it domain-0} can keep this value accurate.  
   4.216  
   4.217  
   4.218 -\section{Domain virtual time}
   4.219 -This progresses at the same pace as cycle counter time, but only while a
   4.220 -domain is executing.  It stops while a domain is de-scheduled.  Therefore the
   4.221 -share of the CPU that a domain receives is indicated by the rate at which
   4.222 -its domain virtual time increases, relative to the rate at which cycle
   4.223 -counter time does so.
   4.224 +\item[Domain virtual time.]
   4.225  
   4.226 -\section{Time interface}
   4.227 -Xen exports some timestamps to guest operating systems through their shared
   4.228 -info page.  Timestamps are provided for system time and wall-clock time.  Xen
   4.229 -also provides the cycle counter values at the time of the last update
   4.230 -allowing guests to calculate the current values.  The cpu frequency and a
   4.231 -scaling factor are provided for guests to convert cycle counter values to
   4.232 -real time.  Since all time stamps need to be updated and read
   4.233 -\emph{atomically} two version numbers are also stored in the shared info
   4.234 -page.
   4.235 +This progresses at the same pace as system time, but only while a
   4.236 +domain is executing --- it stops while a domain is de-scheduled.
   4.237 +Therefore the share of the CPU that a domain receives is indicated by
   4.238 +the rate at which its virtual time increases.
   4.239 +
   4.240 +\end{description}
   4.241 +
   4.242  
   4.243 -Xen will ensure that the time stamps are updated frequently enough to avoid
   4.244 -an overflow of the cycle counter values.  A guest can check if its notion of
   4.245 -time is up-to-date by comparing the version numbers.
   4.246 -
   4.247 -\section{Timer events}
   4.248 +Xen exports timestamps for system time and wall-clock time to guest
   4.249 +operating systems through a shared page of memory.  Xen also provides
   4.250 +the cycle counter time at the instant the timestamps were calculated,
   4.251 +and the CPU frequency in Hertz.  This allows the guest to extrapolate
   4.252 +system and wall-clock times accurately based on the current cycle
   4.253 +counter time.
   4.254  
   4.255 -Xen maintains a periodic timer (currently with a 10ms period) which sends a
   4.256 -timer event to the currently executing domain.  This allows Guest OSes to
   4.257 -keep track of the passing of time when executing.  The scheduler also
   4.258 -arranges for a newly activated domain to receive a timer event when
   4.259 -scheduled so that the Guest OS can adjust to the passage of time while it
   4.260 -has been inactive.
   4.261 +Since all time stamps need to be updated and read \emph{atomically}
   4.262 +two version numbers are also stored in the shared info page. The 
   4.263 +first is incremented prior to an update, while the second is only
   4.264 +incremented afterwards. Thus a guest can be sure that it read a consistent 
   4.265 +state by checking the two version numbers are equal. 
   4.266  
   4.267 -In addition, Xen exports a hypercall interface to each domain which allows
   4.268 -them to request a timer event sent to them at the specified system
   4.269 -time.  Guest OSes may use this timer to implement timeout values when they
   4.270 -block.
   4.271 +Xen includes a periodic ticker which sends a timer event to the
   4.272 +currently executing domain every 10ms.  The Xen scheduler also sends a
   4.273 +timer event whenever a domain is scheduled; this allows the guest OS
   4.274 +to adjust for the time that has passed while it has been inactive.  In
   4.275 +addition, Xen allows each domain to request that they receive a timer
   4.276 +event sent at a specified system time.  Guest OSes may use this timer to
   4.277 +implement timeout values when they block.
   4.278 +
   4.279  
   4.280  \chapter{Memory}
   4.281  
   4.282 -The hypervisor is responsible for providing memory to each of the
   4.283 -domains running over it.  However, the Xen hypervisor's duty is
   4.284 -restricted to managing physical memory and to policying page table
   4.285 -updates.  All other memory management functions are handled
   4.286 -externally.  Start-of-day issues such as building initial page tables
   4.287 -for a domain, loading its kernel image and so on are done by the {\it
   4.288 -domain builder} running in user-space in {\it domain0}.  Paging to
   4.289 -disk and swapping is handled by the guest operating systems
   4.290 -themselves, if they need it.
   4.291 +Xen is responsible for managing the allocation of physical memory to
   4.292 +domains, and for ensuring safe use of the paging and segmentation
   4.293 +hardware.
   4.294 +
   4.295 +
   4.296 +\section{Memory Allocation}
   4.297 +
   4.298 +Xen resides within a small fixed portion of physical memory and
   4.299 +reserves the top 64MB of every virtual address space. The remaining
   4.300 +physical memory is available for allocation to domains at a page
   4.301 +granularity.  Xen tracks the ownership and use of each page, which
   4.302 +allows it to enforce secure partitioning between domains.
   4.303  
   4.304 -On a Xen-based system, the hypervisor itself runs in {\it ring 0}.  It
   4.305 -has full access to the physical memory available in the system and is
   4.306 -responsible for allocating portions of it to the domains.  Guest
   4.307 -operating systems run in and use {\it rings 1}, {\it 2} and {\it 3} as
   4.308 -they see fit, aside from the fact that segmentation is used to prevent
   4.309 -the guest OS from accessing a portion of the linear address space that
   4.310 -is reserved for use by the hypervisor.  This approach allows
   4.311 -transitions between the guest OS and hypervisor without flushing the
   4.312 -TLB.  We expect most guest operating systems will use ring 1 for their
   4.313 -own operation and place applications (if they support such a notion)
   4.314 -in ring 3.
   4.315 +Each domain has a maximum and current physical memory allocation. 
   4.316 +A guest OS may run a `balloon driver' to dynamically adjust its 
   4.317 +current memory allocation up to its limit. 
   4.318 +
   4.319  
   4.320 -\section{Physical Memory Allocation}
   4.321 -The hypervisor reserves a small fixed portion of physical memory at
   4.322 -system boot time.  This special memory region is located at the
   4.323 -beginning of physical memory and is mapped at the very top of every
   4.324 -virtual address space.
   4.325 +\section{Page Table Updates}
   4.326 +
   4.327 +In the default mode of operation, Xen enforces read-only access to
   4.328 +page tables and requires guest operating systems to explicitly request
   4.329 +any modifications.  Xen validates all such requests and only applies
   4.330 +updates that it deems safe.  This is necessary to prevent domains from
   4.331 +adding arbitrary mappings to their page tables.
   4.332  
   4.333 -Any physical memory that is not used directly by the hypervisor is divided into
   4.334 -pages and is available for allocation to domains.  The hypervisor tracks which
   4.335 -pages are free and which pages have been allocated to each domain.  When a new
   4.336 -domain is initialized, the hypervisor allocates it pages drawn from the free 
   4.337 -list.  The amount of memory required by the domain is passed to the hypervisor
   4.338 -as one of the parameters for new domain initialization by the domain builder.
   4.339 +To aid validation, Xen associates a type and reference count with each
   4.340 +memory page. A page has one of the following
   4.341 +mutually-exclusive types at any point in time: page directory ({\sf
   4.342 +PD}), page table ({\sf PT}), local descriptor table ({\sf LDT}),
   4.343 +global descriptor table ({\sf GDT}), or writable ({\sf RW}). Note that
   4.344 +a guest OS may always create readable mappings of its own memory 
   4.345 +regardless of its current type. 
   4.346 +%%% XXX: possibly explain more about ref count 'lifecyle' here?
   4.347 +This mechanism is used to
   4.348 +maintain the invariants required for safety; for example, a domain
   4.349 +cannot have a writable mapping to any part of a page table as this
   4.350 +would require the page concerned to simultaneously be of types {\sf
   4.351 +  PT} and {\sf RW}.
   4.352  
   4.353 -Domains can never be allocated further memory beyond that which was
   4.354 -requested for them on initialization.  However, a domain can return
   4.355 -pages to the hypervisor if it discovers that its memory requirements
   4.356 -have diminished.
   4.357 +
   4.358 +%\section{Writable Page Tables}
   4.359  
   4.360 -% put reasons for why pages might be returned here.
   4.361 -\section{Page Table Updates}
   4.362 -In addition to managing physical memory allocation, the hypervisor is also in
   4.363 -charge of performing page table updates on behalf of the domains.  This is 
   4.364 -neccessary to prevent domains from adding arbitrary mappings to their page
   4.365 -tables or introducing mappings to other's page tables.
   4.366 +Xen also provides an alternative mode of operation in which guests be
   4.367 +have the illusion that their page tables are directly writable.  Of
   4.368 +course this is not really the case, since Xen must still validate
   4.369 +modifications to ensure secure partitioning. To this end, Xen traps
   4.370 +any write attempt to a memory page of type {\sf PT} (i.e., that is
   4.371 +currently part of a page table).  If such an access occurs, Xen
   4.372 +temporarily allows write access to that page while at the same time
   4.373 +{\em disconnecting} it from the page table that is currently in
   4.374 +use. This allows the guest to safely make updates to the page because
   4.375 +the newly-updated entries cannot be used by the MMU until Xen
   4.376 +revalidates and reconnects the page.
   4.377 +Reconnection occurs automatically in a number of situations: for
   4.378 +example, when the guest modifies a different page-table page, when the
   4.379 +domain is preempted, or whenever the guest uses Xen's explicit
   4.380 +page-table update interfaces.
   4.381  
   4.382 -\section{Writabel Page Tables}
   4.383 -A domain can also request write access to its page tables.  In this
   4.384 -mode, Xen notes write attempts to page table pages and makes the page
   4.385 -temporarily writable.  In-use page table pages are also disconnect
   4.386 -from the page directory.  The domain can now update entries in these
   4.387 -page table pages without the assistance of Xen.  As soon as the
   4.388 -writabel page table pages get used as page table pages, Xen makes the
   4.389 -pages read-only again and revalidates the entries in the pages.
   4.390  
   4.391  \section{Segment Descriptor Tables}
   4.392  
   4.393 -On boot a guest is supplied with a default GDT, which is {\em not}
   4.394 -taken from its own memory allocation.  If the guest wishes to use other
   4.395 -than the default `flat' ring-1 and ring-3 segments that this default
   4.396 -table provides, it must register a custom GDT and/or LDT with Xen,
   4.397 -allocated from its own memory.
   4.398 +On boot a guest is supplied with a default GDT, which does not reside
   4.399 +within its own memory allocation.  If the guest wishes to use other
   4.400 +than the default `flat' ring-1 and ring-3 segments that this GDT
   4.401 +provides, it must register a custom GDT and/or LDT with Xen,
   4.402 +allocated from its own memory. Note that a number of GDT 
   4.403 +entries are reserved by Xen -- any custom GDT must also include
   4.404 +sufficent space for these entries. 
   4.405  
   4.406 +For example, the following hypercall is used to specify a new GDT: 
   4.407 +
   4.408 +\begin{quote}
   4.409  int {\bf set\_gdt}(unsigned long *{\em frame\_list}, int {\em entries})
   4.410  
   4.411  {\em frame\_list}: An array of up to 16 page frames within which the
   4.412 @@ -253,12 +274,18 @@ mappings, no use as a page-table page, a
   4.413  
   4.414  {\em entries}: The number of descriptor-entry slots in the GDT.  Note
   4.415  that the table must be large enough to contain Xen's reserved entries;
   4.416 -thus we must have '{\em entries $>$ LAST\_RESERVED\_GDT\_ENTRY}'.
   4.417 +thus we must have `{\em entries $>$ LAST\_RESERVED\_GDT\_ENTRY}\ '.
   4.418  Note also that, after registering the GDT, slots {\em FIRST\_} through
   4.419  {\em LAST\_RESERVED\_GDT\_ENTRY} are no longer usable by the guest and
   4.420  may be overwritten by Xen.
   4.421 +\end{quote}
   4.422 +
   4.423 +
   4.424 +XXX SMH: HERE 
   4.425 +
   4.426  
   4.427  \section{Pseudo-Physical Memory}
   4.428 +
   4.429  The usual problem of external fragmentation means that a domain is
   4.430  unlikely to receive a contiguous stretch of physical memory.  However,
   4.431  most guest operating systems do not have built-in support for
   4.432 @@ -276,6 +303,21 @@ tables contain real physical addresses. 
   4.433  to {\it real physical} addresses is needed on page table updates and
   4.434  also on remapping memory regions with the guest OS.
   4.435  
   4.436 +\section{start of day xxx}
   4.437 +
   4.438 +
   4.439 +Start-of-day issues such as building initial page tables
   4.440 +for a domain, loading its kernel image and so on are done by the {\it
   4.441 +domain builder} running in user-space in {\it domain0}.  Paging to
   4.442 +disk and swapping is handled by the guest operating systems
   4.443 +themselves, if they need it.
   4.444 +
   4.445 +The amount of memory required by the domain is passed to the hypervisor
   4.446 +as one of the parameters for new domain initialization by the domain builder.
   4.447 +
   4.448 +
   4.449 +
   4.450 +
   4.451  
   4.452  
   4.453  \chapter{Network I/O}
   4.454 @@ -418,6 +460,8 @@ Xen's internal scheduler API.
   4.455  More information on the characteristics and use of these schedulers is
   4.456  available in { \tt Sched-HOWTO.txt }.
   4.457  
   4.458 +\begin{comment}
   4.459 +
   4.460  \section{Scheduling API}
   4.461  
   4.462  The scheduling API is used by both the schedulers described above and should
   4.463 @@ -752,13 +796,19 @@ For more information, see the manual pag
   4.464  xentrace\_format} and {\tt xentrace\_cpusplit}.
   4.465  
   4.466  
   4.467 -\chapter{Hypervisor calls}
   4.468 +\appendix
   4.469 +
   4.470 +\newcommand{\hypercall}[1]{\vspace{5mm}{\large\sf #1}}
   4.471  
   4.472 -\section{ set\_trap\_table(trap\_info\_t *table)} 
   4.473 +\chapter{Xen Hypercalls}
   4.474 +
   4.475 +\hypercall{ set\_trap\_table(trap\_info\_t *table)} 
   4.476  
   4.477  Install trap handler table.
   4.478  
   4.479 -\section{ mmu\_update(mmu\_update\_t *req, int count, int *success\_count)} 
   4.480 +
   4.481 +\hypercall{ mmu\_update(mmu\_update\_t *req, int count, int *success\_count)} 
   4.482 +
   4.483  Update the page table for the domain. Updates can be batched.
   4.484  success\_count will be updated to report the number of successfull
   4.485  updates.  The update types are:
   4.486 @@ -769,24 +819,35 @@ updates.  The update types are:
   4.487  
   4.488  {\it MMU\_EXTENDED\_COMMAND}:
   4.489  
   4.490 -\section{ set\_gdt(unsigned long *frame\_list, int entries)} 
   4.491 +
   4.492 +\hypercall{ set\_gdt(unsigned long *frame\_list, int entries)} 
   4.493 +
   4.494  Set the global descriptor table - virtualization for lgdt.
   4.495  
   4.496 -\section{ stack\_switch(unsigned long ss, unsigned long esp)} 
   4.497 +
   4.498 +\hypercall{ stack\_switch(unsigned long ss, unsigned long esp)} 
   4.499 +
   4.500  Request context switch from hypervisor.
   4.501  
   4.502 -\section{ set\_callbacks(unsigned long event\_selector, unsigned long event\_address,
   4.503 +
   4.504 +\hypercall{ set\_callbacks(unsigned long event\_selector, unsigned long event\_address,
   4.505                          unsigned long failsafe\_selector, unsigned
   4.506 - long failsafe\_address) } Register OS event processing routine.  In
   4.507 - Linux both the event\_selector and failsafe\_selector are the
   4.508 - kernel's CS.  The value event\_address specifies the address for an
   4.509 - interrupt handler dispatch routine and failsafe\_address specifies a
   4.510 - handler for application faults.
   4.511 + long failsafe\_address) }
   4.512  
   4.513 -\section{ fpu\_taskswitch(void)} 
   4.514 +Register OS event processing routine.  In
   4.515 +Linux both the event\_selector and failsafe\_selector are the
   4.516 +kernel's CS.  The value event\_address specifies the address for an
   4.517 +interrupt handler dispatch routine and failsafe\_address specifies a
   4.518 +handler for application faults.
   4.519 +
   4.520 +
   4.521 +\hypercall{ fpu\_taskswitch(void)} 
   4.522 +
   4.523  Notify hypervisor that fpu registers needed to be save on context switch.
   4.524  
   4.525 -\section{ sched\_op(unsigned long op)} 
   4.526 +
   4.527 +\hypercall{ sched\_op(unsigned long op)} 
   4.528 +
   4.529  Request scheduling operation from hypervisor. The options are: {\it
   4.530  yield}, {\it block}, and {\it shutdown}.  {\it yield} keeps the
   4.531  calling domain run-able but may cause a reschedule if other domains
   4.532 @@ -795,7 +856,9 @@ queue and the domains sleeps until an ev
   4.533  shutdown} is used to end the domain's execution and allows to specify
   4.534  whether the domain should reboot, halt or suspend..
   4.535  
   4.536 -\section{ dom0\_op(dom0\_op\_t *op)} 
   4.537 +
   4.538 +\hypercall{ dom0\_op(dom0\_op\_t *op)} 
   4.539 +
   4.540  Administrative domain operations for domain management. The options are:
   4.541  
   4.542  {\it DOM0\_CREATEDOMAIN}: create new domain, specifying the name and memory usage
   4.543 @@ -855,47 +918,73 @@ in kilobytes.
   4.544  {\it DOM0\_SETDOMAINVMASSIST}: set domain VM assist options
   4.545  
   4.546  
   4.547 -\section{ set\_debugreg(int reg, unsigned long value)}
   4.548 +\hypercall{ set\_debugreg(int reg, unsigned long value)}
   4.549 +
   4.550  set debug register reg to value
   4.551  
   4.552 -\section{ get\_debugreg(int reg)}
   4.553 +
   4.554 +\hypercall{ get\_debugreg(int reg)}
   4.555 +
   4.556   get the debug register reg
   4.557  
   4.558 -\section{ update\_descriptor(unsigned long ma, unsigned long word1, unsigned long word2)} 
   4.559 +
   4.560 +\hypercall{ update\_descriptor(unsigned long ma, unsigned long word1, unsigned long word2)} 
   4.561  
   4.562 -\section{ set\_fast\_trap(int idx)}
   4.563 +
   4.564 +\hypercall{ set\_fast\_trap(int idx)}
   4.565 +
   4.566   install traps to allow guest OS to bypass hypervisor
   4.567  
   4.568 -\section{ dom\_mem\_op(unsigned int op, unsigned long *extent\_list, unsigned long nr\_extents, unsigned int extent\_order)}
   4.569 +
   4.570 +\hypercall{ dom\_mem\_op(unsigned int op, unsigned long *extent\_list, unsigned long nr\_extents, unsigned int extent\_order)}
   4.571 +
   4.572  Increase or decrease memory reservations for guest OS
   4.573  
   4.574 -\section{ multicall(void *call\_list, int nr\_calls)}
   4.575 +
   4.576 +\hypercall{ multicall(void *call\_list, int nr\_calls)}
   4.577 +
   4.578  Execute a series of hypervisor calls
   4.579  
   4.580 -\section{ update\_va\_mapping(unsigned long page\_nr, unsigned long val, unsigned long flags)}
   4.581 +
   4.582 +\hypercall{ update\_va\_mapping(unsigned long page\_nr, unsigned long val, unsigned long flags)}
   4.583  
   4.584 -\section{ set\_timer\_op(uint64\_t timeout)} 
   4.585 +
   4.586 +\hypercall{ set\_timer\_op(uint64\_t timeout)} 
   4.587 +
   4.588  Request a timer event to be sent at the specified system time.
   4.589  
   4.590 -\section{ event\_channel\_op(void *op)} 
   4.591 -Iinter-domain event-channel management.
   4.592 +
   4.593 +\hypercall{ event\_channel\_op(void *op)} 
   4.594  
   4.595 -\section{ xen\_version(int cmd)}
   4.596 +Inter-domain event-channel management.
   4.597 +
   4.598 +
   4.599 +\hypercall{ xen\_version(int cmd)}
   4.600 +
   4.601  Request Xen version number.
   4.602  
   4.603 -\section{ console\_io(int cmd, int count, char *str)}
   4.604 +
   4.605 +\hypercall{ console\_io(int cmd, int count, char *str)}
   4.606 +
   4.607  Interact with the console, operations are:
   4.608  
   4.609  {\it CONSOLEIO\_write}: Output count characters from buffer str.
   4.610  
   4.611  {\it CONSOLEIO\_read}: Input at most count characters into buffer str.
   4.612  
   4.613 -\section{ physdev\_op(void *physdev\_op)}
   4.614 +
   4.615 +\hypercall{ physdev\_op(void *physdev\_op)}
   4.616  
   4.617 -\section{ grant\_table\_op(unsigned int cmd, void *uop, unsigned int count)}
   4.618 +
   4.619 +\hypercall{ grant\_table\_op(unsigned int cmd, void *uop, unsigned int count)}
   4.620 +
   4.621  
   4.622 -\section{ vm\_assist(unsigned int cmd, unsigned int type)}
   4.623 +\hypercall{ vm\_assist(unsigned int cmd, unsigned int type)}
   4.624 +
   4.625  
   4.626 -\section{ update\_va\_mapping\_otherdomain(unsigned long page\_nr, unsigned long val, unsigned long flags, uint16\_t domid)}
   4.627 +\hypercall{ update\_va\_mapping\_otherdomain(unsigned long page\_nr, unsigned long val, unsigned long flags, uint16\_t domid)}
   4.628 +
   4.629 +
   4.630 +\end{comment}
   4.631  
   4.632  \end{document}
     5.1 --- a/docs/src/user.tex	Fri Oct 29 17:26:59 2004 +0000
     5.2 +++ b/docs/src/user.tex	Fri Oct 29 17:57:57 2004 +0000
     5.3 @@ -17,12 +17,19 @@
     5.4  {\Huge \bf Users' manual} \\[4mm]
     5.5  {\huge Xen v2.0 for x86} \\[80mm]
     5.6  
     5.7 -{\Large Xen is Copyright (c) 2004, The Xen Team} \\[3mm]
     5.8 +{\Large Xen is Copyright (c) 2002-2004, The Xen Team} \\[3mm]
     5.9  {\Large University of Cambridge, UK} \\[20mm]
    5.10 -{\large Last updated on 26th October, 2004}
    5.11  \end{tabular}
    5.12 +\end{center}
    5.13 +
    5.14 +{\bf
    5.15 +DISCLAIMER: This documentation is currently under active development
    5.16 +and as such there may be mistakes and omissions --- watch out for
    5.17 +these and please report any you find to the developer's mailing list.
    5.18 +Contributions of material, suggestions and corrections are welcome.
    5.19 +}
    5.20 +
    5.21  \vfill
    5.22 -\end{center}
    5.23  \cleardoublepage
    5.24  
    5.25  % TABLE OF CONTENTS
    5.26 @@ -50,15 +57,6 @@
    5.27  \part{Introduction and Tutorial}
    5.28  \chapter{Introduction}
    5.29  
    5.30 -{\bf
    5.31 -DISCLAIMER: This documentation is currently under active development
    5.32 -and as such there may be mistakes and omissions --- watch out for
    5.33 -these and please report any you find to the developer's mailing list.
    5.34 -Contributions of material, suggestions and corrections are welcome.
    5.35 -}
    5.36 -
    5.37 -\vspace{5mm}
    5.38 -
    5.39  Xen is a { \em paravirtualising } virtual machine monitor (VMM), or
    5.40  `hypervisor', for the x86 processor architecture.  Xen can securely
    5.41  execute multiple virtual machines on a single physical system with