view docs/src/interface.tex @ 7176:0e1838de9db8

Move XendDomainInfo.{create,recreate,parseConfig} to the top level of the
domain. This allows us to refer to them using an import statement, rather than
a from .. import. This is a step towards getting rid of the xroot hack. All
other references to XendDomainInfo methods need to be doubly qualified (once
for the module, once for the class).

Remove XendDomainDict, replacing it with a simple dictionary, folding the
get_by_name method into XendDomain.

Replace XendDomain.refresh_lock with a domains_lock which goes around any
reference to XendDomain.domains or anything that will create or destroy a
domain. This serialises most accesses through XendDomain, ensuring that we will
not return stale state when racing against the watches fired in separate
threads. This should have fixed bugs #270 and #234.

Added a number of domain_get_xyz methods. Those named xyz_nr are to allow
components internal to XendDomain (XendDomainInfo, XendCheckpoint) to call back
into XendDomain without triggering further calls to XendDomain.refresh. The
other methods simply make it clear which fallback behaviour is expected.

Replace XendDomainInfo.domain_exists with XendDomainInfo.domain_by_name; the
internals of this method needed to change to match those changes above, and it
has been a misnomer for some time.

Signed-off-by: Ewan Mellor <ewan@xensource.com>
author emellor@ewan
date Tue Oct 04 02:21:28 2005 +0100 (2005-10-04)
parents 06d84bf87159
children c8fdb0caa77b
line source
1 \documentclass[11pt,twoside,final,openright]{report}
2 \usepackage{a4,graphicx,html,setspace,times}
3 \usepackage{comment,parskip}
4 \setstretch{1.15}
6 \begin{document}
9 \pagestyle{empty}
10 \begin{center}
11 \vspace*{\fill}
12 \includegraphics{figs/xenlogo.eps}
13 \vfill
14 \vfill
15 \vfill
16 \begin{tabular}{l}
17 {\Huge \bf Interface manual} \\[4mm]
18 {\huge Xen v2.0 for x86} \\[80mm]
20 {\Large Xen is Copyright (c) 2002-2004, The Xen Team} \\[3mm]
21 {\Large University of Cambridge, UK} \\[20mm]
22 \end{tabular}
23 \end{center}
25 {\bf
26 DISCLAIMER: This documentation is currently under active development
27 and as such there may be mistakes and omissions --- watch out for
28 these and please report any you find to the developer's mailing list.
29 Contributions of material, suggestions and corrections are welcome.
30 }
32 \vfill
33 \cleardoublepage
36 \pagestyle{plain}
37 \pagenumbering{roman}
38 { \parskip 0pt plus 1pt
39 \tableofcontents }
40 \cleardoublepage
43 \pagenumbering{arabic}
44 \raggedbottom
45 \widowpenalty=10000
46 \clubpenalty=10000
47 \parindent=0pt
48 \parskip=5pt
49 \renewcommand{\topfraction}{.8}
50 \renewcommand{\bottomfraction}{.8}
51 \renewcommand{\textfraction}{.2}
52 \renewcommand{\floatpagefraction}{.8}
53 \setstretch{1.1}
55 \chapter{Introduction}
57 Xen allows the hardware resources of a machine to be virtualized and
58 dynamically partitioned, allowing multiple different {\em guest}
59 operating system images to be run simultaneously. Virtualizing the
60 machine in this manner provides considerable flexibility, for example
61 allowing different users to choose their preferred operating system
62 (e.g., Linux, NetBSD, or a custom operating system). Furthermore, Xen
63 provides secure partitioning between virtual machines (known as
64 {\em domains} in Xen terminology), and enables better resource
65 accounting and QoS isolation than can be achieved with a conventional
66 operating system.
68 Xen essentially takes a `whole machine' virtualization approach as
69 pioneered by IBM VM/370. However, unlike VM/370 or more recent
70 efforts such as VMWare and Virtual PC, Xen does not attempt to
71 completely virtualize the underlying hardware. Instead parts of the
72 hosted guest operating systems are modified to work with the VMM; the
73 operating system is effectively ported to a new target architecture,
74 typically requiring changes in just the machine-dependent code. The
75 user-level API is unchanged, and so existing binaries and operating
76 system distributions work without modification.
78 In addition to exporting virtualized instances of CPU, memory, network
79 and block devices, Xen exposes a control interface to manage how these
80 resources are shared between the running domains. Access to the
81 control interface is restricted: it may only be used by one
82 specially-privileged VM, known as {\em domain 0}. This domain is a
83 required part of any Xen-based server and runs the application software
84 that manages the control-plane aspects of the platform. Running the
85 control software in {\it domain 0}, distinct from the hypervisor
86 itself, allows the Xen framework to separate the notions of
87 mechanism and policy within the system.
90 %% chapter Virtual Architecture moved to architecture.tex
91 \include{src/interface/architecture}
93 %% chapter Memory moved to memory.tex
94 \include{src/interface/memory}
96 %% chapter Devices moved to devices.tex
97 \include{src/interface/devices}
99 %% chapter Further Information moved to further_info.tex
100 \include{src/interface/further_info}
103 \appendix
105 %% chapter hypercalls moved to hypercalls.tex
106 \include{src/interface/hypercalls}
109 %%
110 %% XXX SMH: not really sure how useful below is -- if it's still
111 %% actually true, might be useful for someone wanting to write a
112 %% new scheduler... not clear how many of them there are...
113 %%
115 %% \include{src/interface/scheduling}
116 %% scheduling information moved to scheduling.tex
117 %% still commented out
121 %%
122 %% XXX SMH: we probably should have something in here on debugging
123 %% etc; this is a kinda developers manual and many devs seem to
124 %% like debugging support :^)
125 %% Possibly sanitize below, else wait until new xendbg stuff is in
126 %% (and/or kip's stuff?) and write about that instead?
127 %%
129 %% \include{src/interface/debugging}
130 %% debugging information moved to debugging.tex
131 %% still commented out
134 \end{document}