1 | <?xml version="1.0" encoding="UTF-8"?>
|
---|
2 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
---|
3 | "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
---|
4 | <chapter id="TechnicalBackground">
|
---|
5 | <title>Technical background</title>
|
---|
6 |
|
---|
7 | <para>The contents of this chapter are not required to use VirtualBox
|
---|
8 | successfully. The following is provided as additional information for
|
---|
9 | readers who are more familiar with computer architecture and technology and
|
---|
10 | wish to find out more about how VirtualBox works "under the hood".</para>
|
---|
11 |
|
---|
12 | <sect1 id="vboxconfigdata">
|
---|
13 | <title>Where VirtualBox stores its files</title>
|
---|
14 |
|
---|
15 | <para>In VirtualBox, a virtual machine and its settings are described in a
|
---|
16 | virtual machine settings file in XML format. In addition, most virtual
|
---|
17 | machine have one or more virtual hard disks, which are typically
|
---|
18 | represented by disk images (e.g. in VDI format). Where all these files are
|
---|
19 | stored depends on which version of VirtualBox created the machine.</para>
|
---|
20 |
|
---|
21 | <sect2>
|
---|
22 | <title>Machines created by VirtualBox version 4.0 or later</title>
|
---|
23 |
|
---|
24 | <para>Starting with version 4.0, by default, each virtual machine has
|
---|
25 | one directory on your host computer where all the files of that machine
|
---|
26 | are stored -- the XML settings file (with a
|
---|
27 | <computeroutput>.vbox</computeroutput> file extension) and its disk
|
---|
28 | images.</para>
|
---|
29 |
|
---|
30 | <para>By default, this "machine folder" is placed in a common folder
|
---|
31 | called "VirtualBox VMs", which VirtualBox creates in the current system
|
---|
32 | user's home directory. The location of this home directory depends on
|
---|
33 | the conventions of the host operating system:</para>
|
---|
34 |
|
---|
35 | <itemizedlist>
|
---|
36 | <listitem>
|
---|
37 | <para>On Windows, this is
|
---|
38 | <computeroutput>%HOMEDRIVE%%HOMEPATH%</computeroutput>; typically
|
---|
39 | something like <computeroutput>C:\Documents and
|
---|
40 | Settings\Username\</computeroutput>.</para>
|
---|
41 | </listitem>
|
---|
42 |
|
---|
43 | <listitem>
|
---|
44 | <para>On Mac OS X, this is
|
---|
45 | <computeroutput>/Users/username</computeroutput>.</para>
|
---|
46 | </listitem>
|
---|
47 |
|
---|
48 | <listitem>
|
---|
49 | <para>On Linux and Solaris, this is
|
---|
50 | <computeroutput>/home/username</computeroutput>.</para>
|
---|
51 | </listitem>
|
---|
52 | </itemizedlist>
|
---|
53 |
|
---|
54 | <para>For simplicity, we will abbreviate this as
|
---|
55 | <computeroutput>$HOME</computeroutput> below. Using that convention, the
|
---|
56 | common folder for all virtual machines is
|
---|
57 | <computeroutput>$HOME/VirtualBox VMs</computeroutput>.</para>
|
---|
58 |
|
---|
59 | <para>As an example, when you create a virtual machine called "Example
|
---|
60 | VM", you will find that VirtualBox creates<orderedlist>
|
---|
61 | <listitem>
|
---|
62 | <para>the folder <computeroutput>$HOME/VirtualBox VMs/Example
|
---|
63 | VM/</computeroutput> and, in that folder,</para>
|
---|
64 | </listitem>
|
---|
65 |
|
---|
66 | <listitem>
|
---|
67 | <para>the settings file <computeroutput>Example
|
---|
68 | VM.vbox</computeroutput> and</para>
|
---|
69 | </listitem>
|
---|
70 |
|
---|
71 | <listitem>
|
---|
72 | <para>the virtual disk image <computeroutput>Example
|
---|
73 | VM.vdi</computeroutput>.</para>
|
---|
74 | </listitem>
|
---|
75 | </orderedlist></para>
|
---|
76 |
|
---|
77 | <para>This is the default layout if you use the "Create new virtual
|
---|
78 | machine" wizard as described in <xref linkend="gui-createvm" />. Once
|
---|
79 | you start working with the VM, additional files will show up: you will
|
---|
80 | find log files in a subfolder called
|
---|
81 | <computeroutput>Logs</computeroutput>, and once you have taken
|
---|
82 | snapshots, they will appear in a
|
---|
83 | <computeroutput>Snapshots</computeroutput> subfolder. For each VM, you
|
---|
84 | can change the location of its snapshots folder in the VM
|
---|
85 | settings.</para>
|
---|
86 |
|
---|
87 | <para>You can change the default machine folder by selecting
|
---|
88 | "Preferences" from the "File" menu in the VirtualBox main window. Then,
|
---|
89 | in the window that pops up, click on the "General" tab. Alternatively,
|
---|
90 | use <computeroutput>VBoxManage setproperty
|
---|
91 | machinefolder</computeroutput>; see <xref
|
---|
92 | linkend="vboxmanage-setproperty" />.</para>
|
---|
93 | </sect2>
|
---|
94 |
|
---|
95 | <sect2>
|
---|
96 | <title>Machines created by VirtualBox versions before 4.0</title>
|
---|
97 |
|
---|
98 | <para>If you have upgraded to VirtualBox 4.0 from an earlier version of
|
---|
99 | VirtualBox, you probably have settings files and disks in the earlier
|
---|
100 | file system layout.</para>
|
---|
101 |
|
---|
102 | <para>Before version 4.0, VirtualBox separated the machine settings
|
---|
103 | files from virtual disk images. The machine settings files had an
|
---|
104 | <computeroutput>.xml</computeroutput> file extension and resided in a
|
---|
105 | folder called "Machines" under the global VirtualBox configuration
|
---|
106 | directory (see the next section). So, for example, on Linux, this was
|
---|
107 | the hidden <computeroutput>$HOME/.VirtualBox/Machines</computeroutput>
|
---|
108 | directory. The default hard disks folder was called "HardDisks" and
|
---|
109 | resided in the <computeroutput>.VirtualBox</computeroutput> folder as
|
---|
110 | well. Both locations could be changed by the user in the global
|
---|
111 | preferences. (The concept of a "default hard disk folder" has been
|
---|
112 | abandoned with VirtualBox 4.0, since disk images now reside in each
|
---|
113 | machine's folder by default.)</para>
|
---|
114 |
|
---|
115 | <para>The old layout had several severe disadvantages.<orderedlist>
|
---|
116 | <listitem>
|
---|
117 | <para>It was very difficult to move a virtual machine from one
|
---|
118 | host to another because the files involved did not reside in the
|
---|
119 | same folder. In addition, the virtual media of all machines were
|
---|
120 | registered with a global registry in the central VirtualBox
|
---|
121 | settings file
|
---|
122 | (<computeroutput>$HOME/.VirtualBox/VirtualBox.xml</computeroutput>).</para>
|
---|
123 |
|
---|
124 | <para>To move a machine to another host, it was therefore not
|
---|
125 | enough to move the XML settings file and the disk images (which
|
---|
126 | were in different locations), but the hard disk entries from the
|
---|
127 | global media registry XML had to be meticulously copied as well,
|
---|
128 | which was close to impossible if the machine had snapshots and
|
---|
129 | therefore differencing images.</para>
|
---|
130 | </listitem>
|
---|
131 |
|
---|
132 | <listitem>
|
---|
133 | <para>Storing virtual disk images, which can grow very large,
|
---|
134 | under the hidden <computeroutput>.VirtualBox</computeroutput>
|
---|
135 | directory (at least on Linux and Solaris hosts) made many users
|
---|
136 | wonder where their disk space had gone.</para>
|
---|
137 | </listitem>
|
---|
138 | </orderedlist></para>
|
---|
139 |
|
---|
140 | <para>Whereas new VMs created with VirtualBox 4.0 or later will conform
|
---|
141 | to the new layout, for maximum compatibility, old VMs are
|
---|
142 | <emphasis>not</emphasis> converted to the new layout. Otherwise machine
|
---|
143 | settings would be irrevocably broken if a user downgraded from 4.0 back
|
---|
144 | to an older version of VirtualBox.</para>
|
---|
145 | </sect2>
|
---|
146 |
|
---|
147 | <sect2>
|
---|
148 | <title>Global configuration data</title>
|
---|
149 |
|
---|
150 | <para>In addition to the files of the virtual machines, VirtualBox
|
---|
151 | maintains global configuration data. On Linux and Solaris as of VirtualBox 4.3, this
|
---|
152 | is in the hidden directory <computeroutput>$HOME/.config/VirtualBox</computeroutput>, although <computeroutput>$HOME/.VirtualBox</computeroutput> will be used if it exists for compatibility with earlier versions; on Windows (and on Linux and Solaris with VirtualBox 4.2 and earlier) this is in <computeroutput>$HOME/.VirtualBox</computeroutput>; on a Mac it resides in
|
---|
153 | <computeroutput>$HOME/Library/VirtualBox</computeroutput>.</para>
|
---|
154 |
|
---|
155 | <para>VirtualBox creates this configuration directory automatically if
|
---|
156 | necessary. Optionally, you can supply an alternate configuration
|
---|
157 | directory by setting the
|
---|
158 | <computeroutput><literal>VBOX_USER_HOME</literal></computeroutput>
|
---|
159 | environment variable, or additionally on Linux or Solaris by using the standard <computeroutput><literal>XDG_CONFIG_HOME</literal></computeroutput> variable. (Since the global
|
---|
160 | <computeroutput>VirtualBox.xml</computeroutput> settings file points to
|
---|
161 | all other configuration files, this allows for switching between several
|
---|
162 | VirtualBox configurations entirely.)</para>
|
---|
163 |
|
---|
164 | <para>Most importantly, in this directory, VirtualBox stores its global
|
---|
165 | settings file, another XML file called
|
---|
166 | <computeroutput>VirtualBox.xml</computeroutput>. This includes global
|
---|
167 | configuration options and the list of registered virtual machines with
|
---|
168 | pointers to their XML settings files. (Neither the location of this file
|
---|
169 | nor its directory has changed with VirtualBox 4.0.)</para>
|
---|
170 |
|
---|
171 | <para>Before VirtualBox 4.0, all virtual media (disk image files) were
|
---|
172 | also contained in a global registry in this settings file. For
|
---|
173 | compatibility, this media registry still exists if you upgrade
|
---|
174 | VirtualBox and there are media from machines which were created with a
|
---|
175 | version before 4.0. If you have no such machines, then there will be no
|
---|
176 | global media registry; with VirtualBox 4.0, each machine XML file has
|
---|
177 | its own media registry.</para>
|
---|
178 |
|
---|
179 | <para>Also before VirtualBox 4.0, the default "Machines" folder and the
|
---|
180 | default "HardDisks" folder resided under the VirtualBox configuration
|
---|
181 | directory (e.g.
|
---|
182 | <computeroutput>$HOME/.VirtualBox/Machines</computeroutput> on Linux).
|
---|
183 | If you are upgrading from a VirtualBox version before 4.0, files in
|
---|
184 | these directories are not automatically moved in order not to break
|
---|
185 | backwards compatibility.</para>
|
---|
186 | </sect2>
|
---|
187 |
|
---|
188 | <sect2>
|
---|
189 | <title>Summary of 4.0 configuration changes</title>
|
---|
190 |
|
---|
191 | <para>The following table gives a brief overview of the configuration
|
---|
192 | changes between older versions and version 4.0 or above:</para>
|
---|
193 |
|
---|
194 | <table>
|
---|
195 | <title>Configuration changes in version 4.0 or above</title>
|
---|
196 |
|
---|
197 | <tgroup cols="3">
|
---|
198 | <thead>
|
---|
199 | <row>
|
---|
200 | <entry><emphasis role="bold">Setting</emphasis></entry>
|
---|
201 |
|
---|
202 | <entry><emphasis role="bold">Before 4.0</emphasis></entry>
|
---|
203 |
|
---|
204 | <entry><emphasis role="bold">4.0 or above</emphasis></entry>
|
---|
205 | </row>
|
---|
206 | </thead>
|
---|
207 | <tbody>
|
---|
208 | <row>
|
---|
209 | <entry>Default machines folder</entry>
|
---|
210 |
|
---|
211 | <entry><computeroutput>$HOME/.VirtualBox/Machines</computeroutput></entry>
|
---|
212 |
|
---|
213 | <entry><computeroutput>$HOME/VirtualBox
|
---|
214 | VMs</computeroutput></entry>
|
---|
215 | </row>
|
---|
216 |
|
---|
217 | <row>
|
---|
218 | <entry>Default disk image location</entry>
|
---|
219 |
|
---|
220 | <entry><computeroutput>$HOME/.VirtualBox/HardDisks</computeroutput></entry>
|
---|
221 |
|
---|
222 | <entry>In each machine's folder</entry>
|
---|
223 | </row>
|
---|
224 |
|
---|
225 | <row>
|
---|
226 | <entry>Machine settings file extension</entry>
|
---|
227 |
|
---|
228 | <entry><computeroutput>.xml</computeroutput></entry>
|
---|
229 |
|
---|
230 | <entry><computeroutput>.vbox</computeroutput></entry>
|
---|
231 | </row>
|
---|
232 |
|
---|
233 | <row>
|
---|
234 | <entry>Media registry</entry>
|
---|
235 |
|
---|
236 | <entry>Global <computeroutput>VirtualBox.xml</computeroutput>
|
---|
237 | file</entry>
|
---|
238 |
|
---|
239 | <entry>Each machine settings file</entry>
|
---|
240 | </row>
|
---|
241 |
|
---|
242 | <row>
|
---|
243 | <entry>Media registration</entry>
|
---|
244 |
|
---|
245 | <entry>Explicit open/close required</entry>
|
---|
246 |
|
---|
247 | <entry>Automatic on attach</entry>
|
---|
248 | </row>
|
---|
249 | </tbody>
|
---|
250 | </tgroup>
|
---|
251 | </table>
|
---|
252 | </sect2>
|
---|
253 |
|
---|
254 | <sect2>
|
---|
255 | <title>VirtualBox XML files</title>
|
---|
256 |
|
---|
257 | <para>VirtualBox uses XML for both the machine settings files and the
|
---|
258 | global configuration file,
|
---|
259 | <computeroutput>VirtualBox.xml</computeroutput>.</para>
|
---|
260 |
|
---|
261 | <para>All VirtualBox XML files are versioned. When a new settings file
|
---|
262 | is created (e.g. because a new virtual machine is created), VirtualBox
|
---|
263 | automatically uses the settings format of the current VirtualBox
|
---|
264 | version. These files may not be readable if you downgrade to an earlier
|
---|
265 | version of VirtualBox. However, when VirtualBox encounters a settings
|
---|
266 | file from an earlier version (e.g. after upgrading VirtualBox), it
|
---|
267 | attempts to preserve the settings format as much as possible. It will
|
---|
268 | only silently upgrade the settings format if the current settings cannot
|
---|
269 | be expressed in the old format, for example because you enabled a
|
---|
270 | feature that was not present in an earlier version of
|
---|
271 | VirtualBox.<footnote>
|
---|
272 | <para>As an example, before VirtualBox 3.1, it was only possible to
|
---|
273 | enable or disable a single DVD drive in a virtual machine. If it was
|
---|
274 | enabled, then it would always be visible as the secondary master of
|
---|
275 | the IDE controller. With VirtualBox 3.1, DVD drives can be attached
|
---|
276 | to arbitrary slots of arbitrary controllers, so they could be the
|
---|
277 | secondary slave of an IDE controller or in a SATA slot. If you have
|
---|
278 | a machine settings file from an earlier version and upgrade
|
---|
279 | VirtualBox to 3.1 and then move the DVD drive from its default
|
---|
280 | position, this cannot be expressed in the old settings format; the
|
---|
281 | XML machine file would get written in the new format, and a backup
|
---|
282 | file of the old format would be kept.</para>
|
---|
283 | </footnote> In such cases, VirtualBox backs up the old settings file
|
---|
284 | in the virtual machine's configuration directory. If you need to go back
|
---|
285 | to the earlier version of VirtualBox, then you will need to manually
|
---|
286 | copy these backup files back.</para>
|
---|
287 |
|
---|
288 | <para>We intentionally do not document the specifications of the
|
---|
289 | VirtualBox XML files, as we must reserve the right to modify them in the
|
---|
290 | future. We therefore strongly suggest that you do not edit these files
|
---|
291 | manually. VirtualBox provides complete access to its configuration data
|
---|
292 | through its the <computeroutput>VBoxManage</computeroutput> command line
|
---|
293 | tool (see <xref linkend="vboxmanage" />) and its API (see <xref
|
---|
294 | linkend="VirtualBoxAPI" />).</para>
|
---|
295 | </sect2>
|
---|
296 | </sect1>
|
---|
297 |
|
---|
298 | <sect1 id="technical-components">
|
---|
299 | <title>VirtualBox executables and components</title>
|
---|
300 |
|
---|
301 | <para>VirtualBox was designed to be modular and flexible. When the
|
---|
302 | VirtualBox graphical user interface (GUI) is opened and a VM is started,
|
---|
303 | at least three processes are running:<orderedlist>
|
---|
304 | <listitem>
|
---|
305 | <para><computeroutput>VBoxSVC</computeroutput>, the VirtualBox
|
---|
306 | service process which always runs in the background. This process is
|
---|
307 | started automatically by the first VirtualBox client process (the
|
---|
308 | GUI, <computeroutput>VBoxManage</computeroutput>,
|
---|
309 | <computeroutput>VBoxHeadless</computeroutput>, the web service or
|
---|
310 | others) and exits a short time after the last client exits. The
|
---|
311 | service is responsible for bookkeeping, maintaining the state of all
|
---|
312 | VMs, and for providing communication between VirtualBox components.
|
---|
313 | This communication is implemented via COM/XPCOM.<note>
|
---|
314 | <para>When we refer to "clients" here, we mean the local clients
|
---|
315 | of a particular <computeroutput>VBoxSVC</computeroutput> server
|
---|
316 | process, not clients in a network. VirtualBox employs its own
|
---|
317 | client/server design to allow its processes to cooperate, but
|
---|
318 | all these processes run under the same user account on the host
|
---|
319 | operating system, and this is totally transparent to the
|
---|
320 | user.</para>
|
---|
321 | </note></para>
|
---|
322 | </listitem>
|
---|
323 |
|
---|
324 | <listitem>
|
---|
325 | <para>The GUI process, <computeroutput>VirtualBox</computeroutput>,
|
---|
326 | a client application based on the cross-platform Qt library. When
|
---|
327 | started without the <computeroutput>--startvm</computeroutput>
|
---|
328 | option, this application acts as the VirtualBox manager, displaying
|
---|
329 | the VMs and their settings. It then communicates settings and state
|
---|
330 | changes to <computeroutput>VBoxSVC</computeroutput> and also
|
---|
331 | reflects changes effected through other means, e.g.,
|
---|
332 | <computeroutput>VBoxManage</computeroutput>.</para>
|
---|
333 | </listitem>
|
---|
334 |
|
---|
335 | <listitem>
|
---|
336 | <para>If the <computeroutput>VirtualBox</computeroutput> client
|
---|
337 | application is started with the
|
---|
338 | <computeroutput>--startvm</computeroutput> argument, it loads the
|
---|
339 | VMM library which includes the actual hypervisor and then runs a
|
---|
340 | virtual machine and provides the input and output for the
|
---|
341 | guest.</para>
|
---|
342 | </listitem>
|
---|
343 | </orderedlist></para>
|
---|
344 |
|
---|
345 | <para>Any VirtualBox front-end (client) will communicate with the service
|
---|
346 | process and can both control and reflect the current state. For example,
|
---|
347 | either the VM selector or the VM window or VBoxManage can be used to pause
|
---|
348 | the running VM, and other components will always reflect the changed
|
---|
349 | state.</para>
|
---|
350 |
|
---|
351 | <para>The VirtualBox GUI application is only one of several available
|
---|
352 | front ends (clients). The complete list shipped with VirtualBox
|
---|
353 | is:<orderedlist>
|
---|
354 | <listitem>
|
---|
355 | <para><computeroutput>VirtualBox</computeroutput>, the Qt front end
|
---|
356 | implementing the manager and running VMs;</para>
|
---|
357 | </listitem>
|
---|
358 |
|
---|
359 | <listitem>
|
---|
360 | <para><computeroutput>VBoxManage</computeroutput>, a less
|
---|
361 | user-friendly but more powerful alternative, described in <xref
|
---|
362 | linkend="vboxmanage" />.</para>
|
---|
363 | </listitem>
|
---|
364 |
|
---|
365 | <listitem>
|
---|
366 | <para><computeroutput>VBoxSDL</computeroutput>, a simple graphical
|
---|
367 | front end based on the SDL library; see <xref
|
---|
368 | linkend="vboxsdl" />.</para>
|
---|
369 | </listitem>
|
---|
370 |
|
---|
371 | <listitem>
|
---|
372 | <para><computeroutput>VBoxHeadless</computeroutput>, a VM front end
|
---|
373 | which does not directly provide any video output and keyboard/mouse
|
---|
374 | input, but allows redirection via VirtualBox Remote Desktop Extension;
|
---|
375 | see <xref linkend="vboxheadless" />.</para>
|
---|
376 | </listitem>
|
---|
377 |
|
---|
378 | <listitem>
|
---|
379 | <para><computeroutput>vboxwebsrv</computeroutput>, the VirtualBox
|
---|
380 | web service process which allows for controlling a VirtualBox host
|
---|
381 | remotely. This is described in detail in the VirtualBox Software
|
---|
382 | Development Kit (SDK) reference; please see <xref
|
---|
383 | linkend="VirtualBoxAPI" /> for details.</para>
|
---|
384 | </listitem>
|
---|
385 |
|
---|
386 | <listitem>
|
---|
387 | <para>The VirtualBox Python shell, a Python alternative to
|
---|
388 | VBoxManage. This is also described in the SDK reference.</para>
|
---|
389 | </listitem>
|
---|
390 | </orderedlist></para>
|
---|
391 |
|
---|
392 | <para>Internally, VirtualBox consists of many more or less separate
|
---|
393 | components. You may encounter these when analyzing VirtualBox internal
|
---|
394 | error messages or log files. These include:</para>
|
---|
395 |
|
---|
396 | <itemizedlist>
|
---|
397 | <listitem>
|
---|
398 | <para>IPRT, a portable runtime library which abstracts file access,
|
---|
399 | threading, string manipulation, etc. Whenever VirtualBox accesses host
|
---|
400 | operating features, it does so through this library for cross-platform
|
---|
401 | portability.</para>
|
---|
402 | </listitem>
|
---|
403 |
|
---|
404 | <listitem>
|
---|
405 | <para>VMM (Virtual Machine Monitor), the heart of the
|
---|
406 | hypervisor.</para>
|
---|
407 | </listitem>
|
---|
408 |
|
---|
409 | <listitem>
|
---|
410 | <para>EM (Execution Manager), controls execution of guest code.</para>
|
---|
411 | </listitem>
|
---|
412 |
|
---|
413 | <listitem>
|
---|
414 | <para>REM (Recompiled Execution Monitor), provides software emulation
|
---|
415 | of CPU instructions.</para>
|
---|
416 | </listitem>
|
---|
417 |
|
---|
418 | <listitem>
|
---|
419 | <para>TRPM (Trap Manager), intercepts and processes guest traps and
|
---|
420 | exceptions.</para>
|
---|
421 | </listitem>
|
---|
422 |
|
---|
423 | <listitem>
|
---|
424 | <para>HM (Hardware Acceleration Manager), provides support for VT-x
|
---|
425 | and AMD-V.</para>
|
---|
426 | </listitem>
|
---|
427 |
|
---|
428 | <listitem>
|
---|
429 | <para>GIM (Guest Interface Manager), provides support for various
|
---|
430 | paravirtualization interfaces to the guest.</para>
|
---|
431 | </listitem>
|
---|
432 |
|
---|
433 | <listitem>
|
---|
434 | <para>PDM (Pluggable Device Manager), an abstract interface between
|
---|
435 | the VMM and emulated devices which separates device implementations
|
---|
436 | from VMM internals and makes it easy to add new emulated devices.
|
---|
437 | Through PDM, third-party developers can add new virtual devices to
|
---|
438 | VirtualBox without having to change VirtualBox itself.</para>
|
---|
439 | </listitem>
|
---|
440 |
|
---|
441 | <listitem>
|
---|
442 | <para>PGM (Page Manager), a component controlling guest paging.</para>
|
---|
443 | </listitem>
|
---|
444 |
|
---|
445 | <listitem>
|
---|
446 | <para>PATM (Patch Manager), patches guest code to improve and speed up
|
---|
447 | software virtualization.</para>
|
---|
448 | </listitem>
|
---|
449 |
|
---|
450 | <listitem>
|
---|
451 | <para>TM (Time Manager), handles timers and all aspects of time inside
|
---|
452 | guests.</para>
|
---|
453 | </listitem>
|
---|
454 |
|
---|
455 | <listitem>
|
---|
456 | <para>CFGM (Configuration Manager), provides a tree structure which
|
---|
457 | holds configuration settings for the VM and all emulated
|
---|
458 | devices.</para>
|
---|
459 | </listitem>
|
---|
460 |
|
---|
461 | <listitem>
|
---|
462 | <para>SSM (Saved State Manager), saves and loads VM state.</para>
|
---|
463 | </listitem>
|
---|
464 |
|
---|
465 | <listitem>
|
---|
466 | <para>VUSB (Virtual USB), a USB layer which separates emulated USB
|
---|
467 | controllers from the controllers on the host and from USB devices;
|
---|
468 | this also enables remote USB.</para>
|
---|
469 | </listitem>
|
---|
470 |
|
---|
471 | <listitem>
|
---|
472 | <para>DBGF (Debug Facility), a built-in VM debugger.</para>
|
---|
473 | </listitem>
|
---|
474 |
|
---|
475 | <listitem>
|
---|
476 | <para>VirtualBox emulates a number of devices to provide the hardware
|
---|
477 | environment that various guests need. Most of these are standard
|
---|
478 | devices found in many PC compatible machines and widely supported by
|
---|
479 | guest operating systems. For network and storage devices in
|
---|
480 | particular, there are several options for the emulated devices to
|
---|
481 | access the underlying hardware. These devices are managed by
|
---|
482 | PDM.</para>
|
---|
483 | </listitem>
|
---|
484 |
|
---|
485 | <listitem>
|
---|
486 | <para>Guest Additions for various guest operating systems. This is
|
---|
487 | code that is installed from within a virtual machine; see <xref
|
---|
488 | linkend="guestadditions" />.</para>
|
---|
489 | </listitem>
|
---|
490 |
|
---|
491 | <listitem>
|
---|
492 | <para>The "Main" component is special: it ties all the above bits
|
---|
493 | together and is the only public API that VirtualBox provides. All the
|
---|
494 | client processes listed above use only this API and never access the
|
---|
495 | hypervisor components directly. As a result, third-party applications
|
---|
496 | that use the VirtualBox Main API can rely on the fact that it is
|
---|
497 | always well-tested and that all capabilities of VirtualBox are fully
|
---|
498 | exposed. It is this API that is described in the VirtualBox SDK
|
---|
499 | mentioned above (again, see <xref linkend="VirtualBoxAPI" />).</para>
|
---|
500 | </listitem>
|
---|
501 | </itemizedlist>
|
---|
502 | </sect1>
|
---|
503 |
|
---|
504 | <sect1 id="hwvirt">
|
---|
505 | <title>Hardware vs. software virtualization</title>
|
---|
506 |
|
---|
507 | <para>VirtualBox allows software in the virtual machine to run directly on
|
---|
508 | the processor of the host, but an array of complex techniques is employed
|
---|
509 | to intercept operations that would interfere with your host. Whenever the
|
---|
510 | guest attempts to do something that could be harmful to your computer and
|
---|
511 | its data, VirtualBox steps in and takes action. In particular, for lots of
|
---|
512 | hardware that the guest believes to be accessing, VirtualBox simulates a
|
---|
513 | certain "virtual" environment according to how you have configured a
|
---|
514 | virtual machine. For example, when the guest attempts to access a hard
|
---|
515 | disk, VirtualBox redirects these requests to whatever you have configured
|
---|
516 | to be the virtual machine's virtual hard disk -- normally, an image file
|
---|
517 | on your host.</para>
|
---|
518 |
|
---|
519 | <para>Unfortunately, the x86 platform was never designed to be
|
---|
520 | virtualized. Detecting situations in which VirtualBox needs to take
|
---|
521 | control over the guest code that is executing, as described above, is
|
---|
522 | difficult. There are two ways in which to achieve this:<itemizedlist>
|
---|
523 | <listitem>
|
---|
524 | <para>Since 2006, Intel and AMD processors have had support for
|
---|
525 | so-called <emphasis role="bold">"hardware
|
---|
526 | virtualization"</emphasis>. This means that these processors can
|
---|
527 | help VirtualBox to intercept potentially dangerous operations that a
|
---|
528 | guest operating system may be attempting and also makes it easier to
|
---|
529 | present virtual hardware to a virtual machine.</para>
|
---|
530 |
|
---|
531 | <para>These hardware features differ between Intel and AMD
|
---|
532 | processors. Intel named its technology <emphasis
|
---|
533 | role="bold">VT-x</emphasis>; AMD calls theirs <emphasis
|
---|
534 | role="bold">AMD-V</emphasis>. The Intel and AMD support for
|
---|
535 | virtualization is very different in detail, but not very different
|
---|
536 | in principle.<note>
|
---|
537 | <para>On many systems, the hardware virtualization features
|
---|
538 | first need to be enabled in the BIOS before VirtualBox can use
|
---|
539 | them.</para>
|
---|
540 | </note></para>
|
---|
541 | </listitem>
|
---|
542 |
|
---|
543 | <listitem>
|
---|
544 | <para>As opposed to other virtualization software, for many usage
|
---|
545 | scenarios, VirtualBox does not <emphasis>require</emphasis> hardware
|
---|
546 | virtualization features to be present. Through sophisticated
|
---|
547 | techniques, VirtualBox virtualizes many guest operating systems
|
---|
548 | entirely in <emphasis role="bold">software</emphasis>. This means
|
---|
549 | that you can run virtual machines even on older processors which do
|
---|
550 | not support hardware virtualization.</para>
|
---|
551 | </listitem>
|
---|
552 | </itemizedlist></para>
|
---|
553 |
|
---|
554 | <para>Even though VirtualBox does not always require hardware
|
---|
555 | virtualization, enabling it is <emphasis>required</emphasis> in the
|
---|
556 | following scenarios:<itemizedlist>
|
---|
557 | <listitem>
|
---|
558 | <para>Certain rare guest operating systems like OS/2 make use of
|
---|
559 | very esoteric processor instructions that are not supported with our
|
---|
560 | software virtualization. For virtual machines that are configured to
|
---|
561 | contain such an operating system, hardware virtualization is enabled
|
---|
562 | automatically.</para>
|
---|
563 | </listitem>
|
---|
564 |
|
---|
565 | <listitem>
|
---|
566 | <para>VirtualBox's 64-bit guest support (added with version 2.0) and
|
---|
567 | multiprocessing (SMP, added with version 3.0) both require hardware
|
---|
568 | virtualization to be enabled. (This is not much of a limitation
|
---|
569 | since the vast majority of today's 64-bit and multicore CPUs ship
|
---|
570 | with hardware virtualization anyway; the exceptions to this rule are
|
---|
571 | e.g. older Intel Celeron and AMD Opteron CPUs.)</para>
|
---|
572 | </listitem>
|
---|
573 | </itemizedlist></para>
|
---|
574 |
|
---|
575 | <warning>
|
---|
576 | <para>Do not run other hypervisors (open-source or commercial
|
---|
577 | virtualization products) together with VirtualBox! While several
|
---|
578 | hypervisors can normally be <emphasis>installed</emphasis> in parallel,
|
---|
579 | do not attempt to <emphasis>run</emphasis> several virtual machines from
|
---|
580 | competing hypervisors at the same time. VirtualBox cannot track what
|
---|
581 | another hypervisor is currently attempting to do on the same host, and
|
---|
582 | especially if several products attempt to use hardware virtualization
|
---|
583 | features such as VT-x, this can crash the entire host. Also, within
|
---|
584 | VirtualBox, you can mix software and hardware virtualization when
|
---|
585 | running multiple VMs. In certain cases a small performance penalty will
|
---|
586 | be unavoidable when mixing VT-x and software virtualization VMs. We
|
---|
587 | recommend not mixing virtualization modes if maximum performance and low
|
---|
588 | overhead are essential. This does <emphasis>not</emphasis> apply to
|
---|
589 | AMD-V.</para>
|
---|
590 | </warning>
|
---|
591 | </sect1>
|
---|
592 |
|
---|
593 | <sect1 id="gimproviders">
|
---|
594 | <title>Paravirtualization providers</title>
|
---|
595 |
|
---|
596 | <para>VirtualBox allows exposing a paravirtualization interface to
|
---|
597 | facilitate accurate and efficient execution of software within a
|
---|
598 | virtual machine. These interfaces require the guest operating system
|
---|
599 | to recognize their presence and make use of them in order to leverage
|
---|
600 | the benefits of communicating with the VirtualBox hypervisor.</para>
|
---|
601 |
|
---|
602 | <para>Most mainstream, modern guest operating systems, including Windows
|
---|
603 | and Linux, ship with support for one or more paravirtualization interfaces.
|
---|
604 | Hence, there is typically no need to install additional software in the
|
---|
605 | guest (including VirtualBox Guest Additions) to make use of this
|
---|
606 | feature.</para>
|
---|
607 |
|
---|
608 | <para>Exposing a paravirtualization provider to the guest operating
|
---|
609 | system does not rely on the choice of host platforms. For example, the
|
---|
610 | <emphasis>Hyper-V</emphasis> paravirtualization provider can be
|
---|
611 | used for VMs to run on any host platform (supported by VirtualBox) and
|
---|
612 | not just Windows.</para>
|
---|
613 |
|
---|
614 | <para>VirtualBox provides the following interfaces:</para>
|
---|
615 | <itemizedlist>
|
---|
616 | <listitem>
|
---|
617 | <para><emphasis role="bold">Minimal</emphasis>: Announces the
|
---|
618 | presence of a virtualized environment. Additionally, reports the
|
---|
619 | TSC and APIC frequency to the guest operating system. This provider
|
---|
620 | is mandatory for running any Mac OS X guests.</para>
|
---|
621 | </listitem>
|
---|
622 |
|
---|
623 | <listitem>
|
---|
624 | <para><emphasis role="bold">KVM</emphasis>: Presents a Linux KVM
|
---|
625 | hypervisor interface which is recognized by Linux kernels starting
|
---|
626 | with version 2.6.25. VirtualBox's implementation currently supports
|
---|
627 | paravirtualized clocks and SMP spinlocks. This provider is
|
---|
628 | recommended for Linux guests.</para>
|
---|
629 | </listitem>
|
---|
630 |
|
---|
631 | <listitem>
|
---|
632 | <para><emphasis role="bold">Hyper-V</emphasis>: Presents a Microsoft
|
---|
633 | Hyper-V hypervisor interface which is recognized by Windows 7 and newer
|
---|
634 | operating systems. VirtualBox's implementation currently supports
|
---|
635 | paravirtualized clocks, APIC frequency reporting, guest crash reporting
|
---|
636 | and relaxed timer checks. This provider is recommended for Windows
|
---|
637 | guests.
|
---|
638 | </para>
|
---|
639 | </listitem>
|
---|
640 | </itemizedlist>
|
---|
641 | </sect1>
|
---|
642 |
|
---|
643 | <sect1>
|
---|
644 | <title>Details about software virtualization</title>
|
---|
645 |
|
---|
646 | <para>Implementing virtualization on x86 CPUs with no hardware
|
---|
647 | virtualization support is an extraordinarily complex task because the CPU
|
---|
648 | architecture was not designed to be virtualized. The problems can usually
|
---|
649 | be solved, but at the cost of reduced performance. Thus, there is a
|
---|
650 | constant clash between virtualization performance and accuracy.</para>
|
---|
651 |
|
---|
652 | <para>The x86 instruction set was originally designed in the 1970s and
|
---|
653 | underwent significant changes with the addition of protected mode in the
|
---|
654 | 1980s with the 286 CPU architecture and then again with the Intel 386 and
|
---|
655 | its 32-bit architecture. Whereas the 386 did have limited virtualization
|
---|
656 | support for real mode operation (V86 mode, as used by the "DOS Box" of
|
---|
657 | Windows 3.x and OS/2 2.x), no support was provided for virtualizing the
|
---|
658 | entire architecture.</para>
|
---|
659 |
|
---|
660 | <para>In theory, software virtualization is not overly complex. In
|
---|
661 | addition to the four privilege levels ("rings") provided by the hardware
|
---|
662 | (of which typically only two are used: ring 0 for kernel mode and ring 3
|
---|
663 | for user mode), one needs to differentiate between "host context" and
|
---|
664 | "guest context".</para>
|
---|
665 |
|
---|
666 | <para>In "host context", everything is as if no hypervisor was active.
|
---|
667 | This might be the active mode if another application on your host has been
|
---|
668 | scheduled CPU time; in that case, there is a host ring 3 mode and a host
|
---|
669 | ring 0 mode. The hypervisor is not involved.</para>
|
---|
670 |
|
---|
671 | <para>In "guest context", however, a virtual machine is active. So long as
|
---|
672 | the guest code is running in ring 3, this is not much of a problem since a
|
---|
673 | hypervisor can set up the page tables properly and run that code natively
|
---|
674 | on the processor. The problems mostly lie in how to intercept what the
|
---|
675 | guest's kernel does.</para>
|
---|
676 |
|
---|
677 | <para>There are several possible solutions to these problems. One approach
|
---|
678 | is full software emulation, usually involving recompilation. That is, all
|
---|
679 | code to be run by the guest is analyzed, transformed into a form which
|
---|
680 | will not allow the guest to either modify or see the true state of the
|
---|
681 | CPU, and only then executed. This process is obviously highly complex and
|
---|
682 | costly in terms of performance. (VirtualBox contains a recompiler based on
|
---|
683 | QEMU which can be used for pure software emulation, but the recompiler is
|
---|
684 | only activated in special situations, described below.)</para>
|
---|
685 |
|
---|
686 | <para>Another possible solution is paravirtualization, in which only
|
---|
687 | specially modified guest OSes are allowed to run. This way, most of the
|
---|
688 | hardware access is abstracted and any functions which would normally
|
---|
689 | access the hardware or privileged CPU state are passed on to the
|
---|
690 | hypervisor instead. Paravirtualization can achieve good functionality and
|
---|
691 | performance on standard x86 CPUs, but it can only work if the guest OS can
|
---|
692 | actually be modified, which is obviously not always the case.</para>
|
---|
693 |
|
---|
694 | <para>VirtualBox chooses a different approach. When starting a virtual
|
---|
695 | machine, through its ring-0 support kernel driver, VirtualBox has set up
|
---|
696 | the host system so that it can run most of the guest code natively, but it
|
---|
697 | has inserted itself at the "bottom" of the picture. It can then assume
|
---|
698 | control when needed -- if a privileged instruction is executed, the guest
|
---|
699 | traps (in particular because an I/O register was accessed and a device
|
---|
700 | needs to be virtualized) or external interrupts occur. VirtualBox may then
|
---|
701 | handle this and either route a request to a virtual device or possibly
|
---|
702 | delegate handling such things to the guest or host OS. In guest context,
|
---|
703 | VirtualBox can therefore be in one of three states:</para>
|
---|
704 |
|
---|
705 | <para><itemizedlist>
|
---|
706 | <listitem>
|
---|
707 | <para>Guest ring 3 code is run unmodified, at full speed, as much as
|
---|
708 | possible. The number of faults will generally be low (unless the
|
---|
709 | guest allows port I/O from ring 3, something we cannot do as we
|
---|
710 | don't want the guest to be able to access real ports). This is also
|
---|
711 | referred to as "raw mode", as the guest ring-3 code runs
|
---|
712 | unmodified.</para>
|
---|
713 | </listitem>
|
---|
714 |
|
---|
715 | <listitem>
|
---|
716 | <para>For guest code in ring 0, VirtualBox employs a nasty trick: it
|
---|
717 | actually reconfigures the guest so that its ring-0 code is run in
|
---|
718 | ring 1 instead (which is normally not used in x86 operating
|
---|
719 | systems). As a result, when guest ring-0 code (actually running in
|
---|
720 | ring 1) such as a guest device driver attempts to write to an I/O
|
---|
721 | register or execute a privileged instruction, the VirtualBox
|
---|
722 | hypervisor in "real" ring 0 can take over.</para>
|
---|
723 | </listitem>
|
---|
724 |
|
---|
725 | <listitem>
|
---|
726 | <para>The hypervisor (VMM) can be active. Every time a fault occurs,
|
---|
727 | VirtualBox looks at the offending instruction and can relegate it to
|
---|
728 | a virtual device or the host OS or the guest OS or run it in the
|
---|
729 | recompiler.</para>
|
---|
730 |
|
---|
731 | <para>In particular, the recompiler is used when guest code disables
|
---|
732 | interrupts and VirtualBox cannot figure out when they will be
|
---|
733 | switched back on (in these situations, VirtualBox actually analyzes
|
---|
734 | the guest code using its own disassembler). Also, certain privileged
|
---|
735 | instructions such as LIDT need to be handled specially. Finally, any
|
---|
736 | real-mode or protected-mode code (e.g. BIOS code, a DOS guest, or
|
---|
737 | any operating system startup) is run in the recompiler
|
---|
738 | entirely.</para>
|
---|
739 | </listitem>
|
---|
740 | </itemizedlist></para>
|
---|
741 |
|
---|
742 | <para>Unfortunately this only works to a degree. Among others, the
|
---|
743 | following situations require special handling:</para>
|
---|
744 |
|
---|
745 | <para><orderedlist>
|
---|
746 | <listitem>
|
---|
747 | <para>Running ring 0 code in ring 1 causes a lot of additional
|
---|
748 | instruction faults, as ring 1 is not allowed to execute any
|
---|
749 | privileged instructions (of which guest's ring-0 contains plenty).
|
---|
750 | With each of these faults, the VMM must step in and emulate the code
|
---|
751 | to achieve the desired behavior. While this works, emulating
|
---|
752 | thousands of these faults is very expensive and severely hurts the
|
---|
753 | performance of the virtualized guest.</para>
|
---|
754 | </listitem>
|
---|
755 |
|
---|
756 | <listitem>
|
---|
757 | <para>There are certain flaws in the implementation of ring 1 in the
|
---|
758 | x86 architecture that were never fixed. Certain instructions that
|
---|
759 | <emphasis>should</emphasis> trap in ring 1 don't. This affects, for
|
---|
760 | example, the LGDT/SGDT, LIDT/SIDT, or POPF/PUSHF instruction pairs.
|
---|
761 | Whereas the "load" operation is privileged and can therefore be
|
---|
762 | trapped, the "store" instruction always succeed. If the guest is
|
---|
763 | allowed to execute these, it will see the true state of the CPU, not
|
---|
764 | the virtualized state. The CPUID instruction also has the same
|
---|
765 | problem.</para>
|
---|
766 | </listitem>
|
---|
767 |
|
---|
768 | <listitem>
|
---|
769 | <para>A hypervisor typically needs to reserve some portion of the
|
---|
770 | guest's address space (both linear address space and selectors) for
|
---|
771 | its own use. This is not entirely transparent to the guest OS and
|
---|
772 | may cause clashes.</para>
|
---|
773 | </listitem>
|
---|
774 |
|
---|
775 | <listitem>
|
---|
776 | <para>The SYSENTER instruction (used for system calls) executed by
|
---|
777 | an application running in a guest OS always transitions to ring 0.
|
---|
778 | But that is where the hypervisor runs, not the guest OS. In this
|
---|
779 | case, the hypervisor must trap and emulate the instruction even when
|
---|
780 | it is not desirable.</para>
|
---|
781 | </listitem>
|
---|
782 |
|
---|
783 | <listitem>
|
---|
784 | <para>The CPU segment registers contain a "hidden" descriptor cache
|
---|
785 | which is not software-accessible. The hypervisor cannot read, save,
|
---|
786 | or restore this state, but the guest OS may use it.</para>
|
---|
787 | </listitem>
|
---|
788 |
|
---|
789 | <listitem>
|
---|
790 | <para>Some resources must (and can) be trapped by the hypervisor,
|
---|
791 | but the access is so frequent that this creates a significant
|
---|
792 | performance overhead. An example is the TPR (Task Priority) register
|
---|
793 | in 32-bit mode. Accesses to this register must be trapped by the
|
---|
794 | hypervisor, but certain guest operating systems (notably Windows and
|
---|
795 | Solaris) write this register very often, which adversely affects
|
---|
796 | virtualization performance.</para>
|
---|
797 | </listitem>
|
---|
798 | </orderedlist></para>
|
---|
799 |
|
---|
800 | <para>To fix these performance and security issues, VirtualBox contains a
|
---|
801 | Code Scanning and Analysis Manager (CSAM), which disassembles guest code,
|
---|
802 | and the Patch Manager (PATM), which can replace it at runtime.</para>
|
---|
803 |
|
---|
804 | <para>Before executing ring 0 code, CSAM scans it recursively to discover
|
---|
805 | problematic instructions. PATM then performs <emphasis>in-situ
|
---|
806 | </emphasis>patching, i.e. it replaces the instruction with a jump to
|
---|
807 | hypervisor memory where an integrated code generator has placed a more
|
---|
808 | suitable implementation. In reality, this is a very complex task as there
|
---|
809 | are lots of odd situations to be discovered and handled correctly. So,
|
---|
810 | with its current complexity, one could argue that PATM is an advanced
|
---|
811 | <emphasis>in-situ</emphasis> recompiler.</para>
|
---|
812 |
|
---|
813 | <para>In addition, every time a fault occurs, VirtualBox analyzes the
|
---|
814 | offending code to determine if it is possible to patch it in order to
|
---|
815 | prevent it from causing more faults in the future. This approach works
|
---|
816 | well in practice and dramatically improves software virtualization
|
---|
817 | performance.</para>
|
---|
818 | </sect1>
|
---|
819 |
|
---|
820 | <sect1>
|
---|
821 | <title>Details about hardware virtualization</title>
|
---|
822 |
|
---|
823 | <para>With Intel VT-x, there are two distinct modes of CPU operation: VMX
|
---|
824 | root mode and non-root mode.<itemizedlist>
|
---|
825 | <listitem>
|
---|
826 | <para>In root mode, the CPU operates much like older generations of
|
---|
827 | processors without VT-x support. There are four privilege levels
|
---|
828 | ("rings"), and the same instruction set is supported, with the
|
---|
829 | addition of several virtualization specific instruction. Root mode
|
---|
830 | is what a host operating system without virtualization uses, and it
|
---|
831 | is also used by a hypervisor when virtualization is active.</para>
|
---|
832 | </listitem>
|
---|
833 |
|
---|
834 | <listitem>
|
---|
835 | <para>In non-root mode, CPU operation is significantly different.
|
---|
836 | There are still four privilege rings and the same instruction set,
|
---|
837 | but a new structure called VMCS (Virtual Machine Control Structure)
|
---|
838 | now controls the CPU operation and determines how certain
|
---|
839 | instructions behave. Non-root mode is where guest systems
|
---|
840 | run.</para>
|
---|
841 | </listitem>
|
---|
842 | </itemizedlist></para>
|
---|
843 |
|
---|
844 | <para>Switching from root mode to non-root mode is called "VM entry", the
|
---|
845 | switch back is "VM exit". The VMCS includes a guest and host state area
|
---|
846 | which is saved/restored at VM entry and exit. Most importantly, the VMCS
|
---|
847 | controls which guest operations will cause VM exits.</para>
|
---|
848 |
|
---|
849 | <para>The VMCS provides fairly fine-grained control over what the guests
|
---|
850 | can and can't do. For example, a hypervisor can allow a guest to write
|
---|
851 | certain bits in shadowed control registers, but not others. This enables
|
---|
852 | efficient virtualization in cases where guests can be allowed to write
|
---|
853 | control bits without disrupting the hypervisor, while preventing them from
|
---|
854 | altering control bits over which the hypervisor needs to retain full
|
---|
855 | control. The VMCS also provides control over interrupt delivery and
|
---|
856 | exceptions.</para>
|
---|
857 |
|
---|
858 | <para>Whenever an instruction or event causes a VM exit, the VMCS contains
|
---|
859 | information about the exit reason, often with accompanying detail. For
|
---|
860 | example, if a write to the CR0 register causes an exit, the offending
|
---|
861 | instruction is recorded, along with the fact that a write access to a
|
---|
862 | control register caused the exit, and information about source and
|
---|
863 | destination register. Thus the hypervisor can efficiently handle the
|
---|
864 | condition without needing advanced techniques such as CSAM and PATM
|
---|
865 | described above.</para>
|
---|
866 |
|
---|
867 | <para>VT-x inherently avoids several of the problems which software
|
---|
868 | virtualization faces. The guest has its own completely separate address
|
---|
869 | space not shared with the hypervisor, which eliminates potential clashes.
|
---|
870 | Additionally, guest OS kernel code runs at privilege ring 0 in VMX
|
---|
871 | non-root mode, obviating the problems by running ring 0 code at less
|
---|
872 | privileged levels. For example the SYSENTER instruction can transition to
|
---|
873 | ring 0 without causing problems. Naturally, even at ring 0 in VMX non-root
|
---|
874 | mode, any I/O access by guest code still causes a VM exit, allowing for
|
---|
875 | device emulation.</para>
|
---|
876 |
|
---|
877 | <para>The biggest difference between VT-x and AMD-V is that AMD-V provides
|
---|
878 | a more complete virtualization environment. VT-x requires the VMX non-root
|
---|
879 | code to run with paging enabled, which precludes hardware virtualization
|
---|
880 | of real-mode code and non-paged protected-mode software. This typically
|
---|
881 | only includes firmware and OS loaders, but nevertheless complicates VT-x
|
---|
882 | hypervisor implementation. AMD-V does not have this restriction.</para>
|
---|
883 |
|
---|
884 | <para>Of course hardware virtualization is not perfect. Compared to
|
---|
885 | software virtualization, the overhead of VM exits is relatively high. This
|
---|
886 | causes problems for devices whose emulation requires high number of traps.
|
---|
887 | One example is the VGA device in 16-color modes, where not only every I/O
|
---|
888 | port access but also every access to the framebuffer memory must be
|
---|
889 | trapped.</para>
|
---|
890 | </sect1>
|
---|
891 |
|
---|
892 | <sect1 id="nestedpaging">
|
---|
893 | <title>Nested paging and VPIDs</title>
|
---|
894 |
|
---|
895 | <para>In addition to "plain" hardware virtualization, your processor may
|
---|
896 | also support additional sophisticated techniques:<footnote>
|
---|
897 | <para>VirtualBox 2.0 added support for AMD's nested paging; support
|
---|
898 | for Intel's EPT and VPIDs was added with version 2.1.</para>
|
---|
899 | </footnote><itemizedlist>
|
---|
900 | <listitem>
|
---|
901 | <para>A newer feature called <emphasis role="bold">"nested
|
---|
902 | paging"</emphasis> implements some memory management in hardware,
|
---|
903 | which can greatly accelerate hardware virtualization since these
|
---|
904 | tasks no longer need to be performed by the virtualization
|
---|
905 | software.</para>
|
---|
906 |
|
---|
907 | <para>With nested paging, the hardware provides another level of
|
---|
908 | indirection when translating linear to physical addresses. Page
|
---|
909 | tables function as before, but linear addresses are now translated
|
---|
910 | to "guest physical" addresses first and not physical addresses
|
---|
911 | directly. A new set of paging registers now exists under the
|
---|
912 | traditional paging mechanism and translates from guest physical
|
---|
913 | addresses to host physical addresses, which are used to access
|
---|
914 | memory.</para>
|
---|
915 |
|
---|
916 | <para>Nested paging eliminates the overhead caused by VM exits and
|
---|
917 | page table accesses. In essence, with nested page tables the guest
|
---|
918 | can handle paging without intervention from the hypervisor. Nested
|
---|
919 | paging thus significantly improves virtualization
|
---|
920 | performance.</para>
|
---|
921 |
|
---|
922 | <para>On AMD processors, nested paging has been available starting
|
---|
923 | with the Barcelona (K10) architecture -- they call it now "rapid
|
---|
924 | virtualization indexing" (RVI). Intel added support for nested
|
---|
925 | paging, which they call "extended page tables" (EPT), with their
|
---|
926 | Core i7 (Nehalem) processors.</para>
|
---|
927 |
|
---|
928 | <para>If nested paging is enabled, the VirtualBox hypervisor can
|
---|
929 | also use <emphasis role="bold">large pages</emphasis> to reduce TLB
|
---|
930 | usage and overhead. This can yield a performance improvement of up
|
---|
931 | to 5%. To enable this feature for a VM, you need to use the
|
---|
932 | <computeroutput>VBoxManage modifyvm
|
---|
933 | </computeroutput><computeroutput>--largepages</computeroutput>
|
---|
934 | command; see <xref linkend="vboxmanage-modifyvm" />.</para>
|
---|
935 | </listitem>
|
---|
936 |
|
---|
937 | <listitem>
|
---|
938 | <para>On Intel CPUs, another hardware feature called <emphasis
|
---|
939 | role="bold">"Virtual Processor Identifiers" (VPIDs)</emphasis> can
|
---|
940 | greatly accelerate context switching by reducing the need for
|
---|
941 | expensive flushing of the processor's Translation Lookaside Buffers
|
---|
942 | (TLBs).</para>
|
---|
943 |
|
---|
944 | <para>To enable these features for a VM, you need to use the
|
---|
945 | <computeroutput>VBoxManage modifyvm --vtxvpid</computeroutput> and
|
---|
946 | <computeroutput>--largepages</computeroutput> commands; see <xref
|
---|
947 | linkend="vboxmanage-modifyvm" />.</para>
|
---|
948 | </listitem>
|
---|
949 | </itemizedlist></para>
|
---|
950 | </sect1>
|
---|
951 | </chapter>
|
---|