diff options
Diffstat (limited to 'doc/manual/en_US/user_Technical.xml')
| -rw-r--r-- | doc/manual/en_US/user_Technical.xml | 962 |
1 files changed, 962 insertions, 0 deletions
diff --git a/doc/manual/en_US/user_Technical.xml b/doc/manual/en_US/user_Technical.xml new file mode 100644 index 00000000..c1f6c0f5 --- /dev/null +++ b/doc/manual/en_US/user_Technical.xml @@ -0,0 +1,962 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!-- + Copyright (C) 2006-2022 Oracle and/or its affiliates. + + This file is part of VirtualBox base platform packages, as + available from https://www.virtualbox.org. + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation, in version 3 of the + License. + + This program is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, see <https://www.gnu.org/licenses>. + + SPDX-License-Identifier: GPL-3.0-only +--> +<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" +"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"[ +<!ENTITY % all.entities SYSTEM "all-entities.ent"> +%all.entities; +]> +<chapter id="TechnicalBackground"> + + <title>Technical Background</title> + + <para> + This chapter provides additional information for readers who are + familiar with computer architecture and technology and wish to find + out more about how &product-name; works <emphasis>under the + hood</emphasis>. The contents of this chapter are not required + reading in order to use &product-name; successfully. + </para> + + <sect1 id="vboxconfigdata"> + + <title>Where &product-name; Stores its Files</title> + + <para> + In &product-name;, a virtual machine and its settings are + described in a virtual machine settings file in XML format. In + addition, most virtual machines have one or more virtual hard + disks. These are typically represented by disk images, such as + those in VDI format. The location of these files may vary, + depending on the host operating system. See + <xref linkend="vboxconfigdata-machine-folder"/>. + </para> + + <para> + Global configuration data for &product-name; is maintained in + another location on the host. See + <xref linkend="vboxconfigdata-global"/>. + </para> + + <sect2 id="vboxconfigdata-machine-folder"> + + <title>The Machine Folder</title> + + <para> + By default, each virtual machine has a directory on your host + computer where all the files of that machine are stored: the XML + settings file, with a <filename>.vbox</filename> file extension, + and its disk images. This is called the <emphasis>machine + folder</emphasis>. + </para> + + <para> + By default, this machine folder is located in a common folder + called <filename>VirtualBox VMs</filename>, which &product-name; + creates in the current system user's home directory. The + location of this home directory depends on the conventions of + the host operating system, as follows: + </para> + + <itemizedlist> + + <listitem> + <para> + On Windows, this is the location returned by the + <literal>SHGetFolderPath</literal> function of the Windows + system library Shell32.dll, asking for the user profile. A + typical location is + <filename>C:\Users\<replaceable>username</replaceable></filename>. + </para> + </listitem> + + <listitem> + <para> + On Linux, macOS, and Oracle Solaris, this is generally + taken from the environment variable + <filename>$HOME</filename>, except for the user + <literal>root</literal> where it is taken from the account + database. This is a workaround for the frequent trouble + caused by users using &product-name; in combination with the + tool <command>sudo</command>, which by default does not + reset the environment variable <filename>$HOME</filename>. + </para> + + <para> + A typical location on Linux and Oracle Solaris is + <filename>/home/<replaceable>username</replaceable></filename> + and on macOS is + <filename>/Users/<replaceable>username</replaceable></filename>. + </para> + </listitem> + + </itemizedlist> + + <para> + For simplicity, we abbreviate the location of the home directory + as <filename>$HOME</filename>. Using that convention, the common + folder for all virtual machines is <filename>$HOME/VirtualBox + VMs</filename>. + </para> + + <para> + As an example, when you create a virtual machine called "Example + VM", &product-name; creates the following: + </para> + + <itemizedlist> + + <listitem> + <para> + A machine folder: <filename>$HOME/VirtualBox VMs/Example + VM/</filename> + </para> + </listitem> + + <listitem> + <para> + In the machine folder, a settings file: <filename>Example + VM.vbox</filename> + </para> + </listitem> + + <listitem> + <para> + In the machine folder, a virtual disk image: + <filename>Example VM.vdi</filename>. + </para> + </listitem> + + </itemizedlist> + + <para> + This is the default layout if you use the + <emphasis role="bold">Create New Virtual Machine</emphasis> + wizard described in <xref linkend="create-vm-wizard" />. Once you + start working with the VM, additional files are added. Log files + are in a subfolder called <filename>Logs</filename>, and if you + have taken snapshots, they are in a + <filename>Snapshots</filename> subfolder. For each VM, you can + change the location of its snapshots folder in the VM settings. + </para> + + <para> + You can change the default machine folder by selecting + <emphasis role="bold">Preferences</emphasis> from the + <emphasis role="bold">File</emphasis> menu in the &product-name; + main window. Then, in the displayed window, click on the + <emphasis role="bold">General</emphasis> tab. Alternatively, use + the <command>VBoxManage setproperty machinefolder</command> + command. See <xref linkend="vboxmanage-setproperty" />. + </para> + + </sect2> + + <sect2 id="vboxconfigdata-global"> + + <title>Global Settings</title> + + <para> + In addition to the files for the virtual machines, + &product-name; maintains global configuration data in the + following directory: + </para> + + <itemizedlist> + + <listitem> + <para> + <emphasis role="bold">Linux and Oracle Solaris:</emphasis> + <filename>$HOME/.config/VirtualBox</filename>. + </para> + </listitem> + + <listitem> + <para> + <emphasis role="bold">Windows:</emphasis> + <filename>$HOME/.VirtualBox</filename>. + </para> + </listitem> + + <listitem> + <para> + <emphasis role="bold">macOS:</emphasis> + <filename>$HOME/Library/VirtualBox</filename>. + </para> + </listitem> + + </itemizedlist> + + <para> + &product-name; creates this configuration directory + automatically, if necessary. You can specify an alternate + configuration directory by either setting the + <literal>VBOX_USER_HOME</literal> environment variable, or on + Linux or Oracle Solaris by using the standard + <literal>XDG_CONFIG_HOME</literal> variable. Since the global + <filename>VirtualBox.xml</filename> settings file points to all + other configuration files, this enables switching between + several &product-name; configurations. + </para> + + <para> + In this configuration directory, &product-name; stores its + global settings file, an XML file called + <filename>VirtualBox.xml</filename>. This file includes global + configuration options and a list of registered virtual machines + with pointers to their XML settings files. + </para> + + </sect2> + + <sect2 id="vboxconfigdata-summary-locations"> + + <title>Summary of Configuration Data Locations</title> + + <para> + The following table gives a brief overview of the configuration + data locations on an &product-name; host. + </para> + + <table id="table-config-summary" tabstyle="oracle-all"> + <title>Configuration File Locations</title> + <tgroup cols="2"> + <thead> + <row> + <entry><para> + <emphasis role="bold">Setting</emphasis> + </para></entry> + <entry><para> + <emphasis role="bold">Location</emphasis> + </para></entry> + </row> + </thead> + <tbody> + <row> + <entry><para> + Default machines folder + </para></entry> + <entry><para> + <filename>$HOME/VirtualBox VMs</filename> + </para></entry> + </row> + <row> + <entry><para> + Default disk image location + </para></entry> + <entry><para> + In each machine's folder + </para></entry> + </row> + <row> + <entry><para> + Machine settings file extension + </para></entry> + <entry><para> + <filename>.vbox</filename> + </para></entry> + </row> + <row> + <entry><para> + Media registry + </para></entry> + <entry><para> + Each machine settings file + </para> + + + + <para> + Media registration is done automatically when a + storage medium is attached to a VM + </para></entry> + </row> + </tbody> + </tgroup> + </table> + + </sect2> + + <sect2 id="vboxconfigdata-XML-files"> + + <title>&product-name; XML Files</title> + + <para> + &product-name; uses XML for both the machine settings files and + the global configuration file, + <filename>VirtualBox.xml</filename>. + </para> + + <para> + All &product-name; XML files are versioned. When a new settings + file is created, for example because a new virtual machine is + created, &product-name; automatically uses the settings format + of the current &product-name; version. These files may not be + readable if you downgrade to an earlier version of + &product-name;. However, when &product-name; encounters a + settings file from an earlier version, such as after upgrading + &product-name;, it attempts to preserve the settings format as + much as possible. It will only silently upgrade the settings + format if the current settings cannot be expressed in the old + format, for example because you enabled a feature that was not + present in an earlier version of &product-name;. + </para> + + <para> + In such cases, &product-name; backs up the old settings file in + the virtual machine's configuration directory. If you need to go + back to the earlier version of &product-name;, then you will + need to manually copy these backup files back. + </para> + + <para> + We intentionally do not document the specifications of the + &product-name; XML files, as we must reserve the right to modify + them in the future. We therefore strongly suggest that you do + not edit these files manually. &product-name; provides complete + access to its configuration data through its the + <command>VBoxManage</command> command line tool, see + <xref linkend="vboxmanage" /> and its API, see + <xref linkend="VirtualBoxAPI" />. + </para> + + </sect2> + + </sect1> + + <sect1 id="technical-components"> + + <title>&product-name; Executables and Components</title> + + <para> + &product-name; was designed to be modular and flexible. When the + &product-name; graphical user interface (GUI) is opened and a VM + is started, at least the following three processes are running: + </para> + + <itemizedlist> + + <listitem> + <para> + <command>VBoxSVC</command>, the &product-name; service process + which always runs in the background. This process is started + automatically by the first &product-name; client process and + exits a short time after the last client exits. The first + &product-name; service can be &vbox-mgr;, + <command>VBoxManage</command>, + <command>VBoxHeadless</command>, the web service amongst + others. The service is responsible for bookkeeping, + maintaining the state of all VMs, and for providing + communication between &product-name; components. This + communication is implemented using COM/XPCOM. + </para> + + <note> + <para> + When we refer to <emphasis>clients</emphasis> here, we mean + the local clients of a particular <command>VBoxSVC</command> + server process, not clients in a network. &product-name; + employs its own client/server design to allow its processes + to cooperate, but all these processes run under the same + user account on the host operating system, and this is + totally transparent to the user. + </para> + </note> + </listitem> + + <listitem> + <para> + The GUI process, <command>VirtualBoxVM</command>, a client + application based on the cross-platform Qt library. When + started without the <option>--startvm</option> option, this + application acts as &vbox-mgr;, displaying the VMs and their + settings. It then communicates settings and state changes to + <command>VBoxSVC</command> and also reflects changes effected + through other means, such as the <command>VBoxManage</command> + command. + </para> + </listitem> + + <listitem> + <para> + If the <command>VirtualBoxVM</command> client application is + started with the <option>--startvm</option> argument, it loads + the VMM library which includes the actual hypervisor and then + runs a virtual machine and provides the input and output for + the guest. + </para> + </listitem> + + </itemizedlist> + + <para> + Any &product-name; front-end, or client, will communicate with the + service process and can both control and reflect the current + state. For example, either the VM selector or the VM window or + VBoxManage can be used to pause the running VM, and other + components will always reflect the changed state. + </para> + + <para> + The &product-name; GUI application, called &vbox-mgr;, is only one + of several available front ends, or clients. The complete list + shipped with &product-name; is as follows: + </para> + + <itemizedlist> + + <listitem> + <para> + <command>VirtualBoxVM</command>: The Qt front end implementing + &vbox-mgr; and running VMs. + </para> + </listitem> + + <listitem> + <para> + <command>VBoxManage</command>: A less user-friendly but more + powerful alternative. See <xref linkend="vboxmanage" />. + </para> + </listitem> + + <listitem> + <para> + <command>VBoxHeadless</command>: A VM front end which does not + directly provide any video output and keyboard or mouse input, + but enables redirection through the VirtualBox Remote Desktop + Extension. See <xref linkend="vboxheadless" />. + </para> + </listitem> + + <listitem> + <para> + <command>vboxwebsrv</command>: The &product-name; web service + process which enables control of an &product-name; host + remotely. This is described in detail in the &product-name; + Software Development Kit (SDK) reference. See + <xref linkend="VirtualBoxAPI" />. + </para> + </listitem> + + <listitem> + <para> + The &product-name; Python shell: A Python alternative to + <command>VBoxManage</command>. This is also described in the + SDK reference. + </para> + </listitem> + + </itemizedlist> + + <para> + Internally, &product-name; consists of many more or less separate + components. You may encounter these when analyzing &product-name; + internal error messages or log files. These include the following: + </para> + + <itemizedlist> + + <listitem> + <para> + IPRT: A portable runtime library which abstracts file access, + threading, and string manipulation. Whenever &product-name; + accesses host operating features, it does so through this + library for cross-platform portability. + </para> + </listitem> + + <listitem> + <para> + VMM (Virtual Machine Monitor): The heart of the hypervisor. + </para> + </listitem> + + <listitem> + <para> + EM (Execution Manager): Controls execution of guest code. + </para> + </listitem> + + <listitem> + <para> + TRPM (Trap Manager): Intercepts and processes guest traps and + exceptions. + </para> + </listitem> + + <listitem> + <para> + HM (Hardware Acceleration Manager): Provides support for VT-x + and AMD-V. + </para> + </listitem> + + <listitem> + <para> + GIM (Guest Interface Manager): Provides support for various + paravirtualization interfaces to the guest. + </para> + </listitem> + + <listitem> + <para> + PDM (Pluggable Device Manager): An abstract interface between + the VMM and emulated devices which separates device + implementations from VMM internals and makes it easy to add + new emulated devices. Through PDM, third-party developers can + add new virtual devices to &product-name; without having to + change &product-name; itself. + </para> + </listitem> + + <listitem> + <para> + PGM (Page Manager): A component that controls guest paging. + </para> + </listitem> + + <listitem> + <para> + TM (Time Manager): Handles timers and all aspects of time + inside guests. + </para> + </listitem> + + <listitem> + <para> + CFGM (Configuration Manager): Provides a tree structure which + holds configuration settings for the VM and all emulated + devices. + </para> + </listitem> + + <listitem> + <para> + SSM (Saved State Manager): Saves and loads VM state. + </para> + </listitem> + + <listitem> + <para> + VUSB (Virtual USB): A USB layer which separates emulated USB + controllers from the controllers on the host and from USB + devices. This component also enables remote USB. + </para> + </listitem> + + <listitem> + <para> + DBGF (Debug Facility): A built-in VM debugger. + </para> + </listitem> + + <listitem> + <para> + &product-name; emulates a number of devices to provide the + hardware environment that various guests need. Most of these + are standard devices found in many PC compatible machines and + widely supported by guest operating systems. For network and + storage devices in particular, there are several options for + the emulated devices to access the underlying hardware. These + devices are managed by PDM. + </para> + </listitem> + + <listitem> + <para> + Guest Additions for various guest operating systems. This is + code that is installed from within a virtual machine. See + <xref linkend="guestadditions" />. + </para> + </listitem> + + <listitem> + <para> + The "Main" component is special. It ties all the above bits + together and is the only public API that &product-name; + provides. All the client processes listed above use only this + API and never access the hypervisor components directly. As a + result, third-party applications that use the &product-name; + Main API can rely on the fact that it is always well-tested + and that all capabilities of &product-name; are fully exposed. + It is this API that is described in the &product-name; SDK. + See <xref linkend="VirtualBoxAPI" />. + </para> + </listitem> + + </itemizedlist> + + </sect1> + + <sect1 id="hwvirt"> + + <title>Hardware Virtualization</title> + + <para> + &product-name; enables software in the virtual machine to run + directly on the processor of the host, but an array of complex + techniques is employed to intercept operations that would + interfere with your host. Whenever the guest attempts to do + something that could be harmful to your computer and its data, + &product-name; steps in and takes action. In particular, for lots + of hardware that the guest believes to be accessing, + &product-name; simulates a certain <emphasis>virtual</emphasis> + environment according to how you have configured a virtual + machine. For example, when the guest attempts to access a hard + disk, &product-name; redirects these requests to whatever you have + configured to be the virtual machine's virtual hard disk. This is + normally an image file on your host. + </para> + + <para> + Unfortunately, the x86 platform was never designed to be + virtualized. Detecting situations in which &product-name; needs to + take control over the guest code that is executing, as described + above, is difficult. To achieve this, &product-name; uses + <emphasis>hardware virtualization</emphasis>. + </para> + + <para> + Intel and AMD processors have support for hardware virtualization. + This means that these processors can help &product-name; to + intercept potentially dangerous operations that a guest operating + system may be attempting and also makes it easier to present + virtual hardware to a virtual machine. + </para> + + <para> + These hardware features differ between Intel and AMD processors. + Intel named its technology VT-x, AMD calls theirs AMD-V. The Intel + and AMD support for virtualization is very different in detail, + but not very different in principle. + </para> + + <note> + <para> + On many systems, the hardware virtualization features first need + to be enabled in the BIOS before &product-name; can use them. + </para> + </note> + + <para> + Enabling hardware virtualization is <emphasis>required</emphasis> + in the following scenarios: + </para> + + <itemizedlist> + + <listitem> + <para> + Certain rare guest operating systems like OS/2 make use of + very esoteric processor instructions. For virtual machines + that are configured to use such an operating system, hardware + virtualization is enabled automatically. + </para> + </listitem> + + <listitem> + <para> + &product-name;'s 64-bit guest and multiprocessing (SMP) + support both require hardware virtualization to be enabled. + This is not much of a limitation since the vast majority of + 64-bit and multicore CPUs ship with hardware virtualization. + The exceptions to this rule are some legacy Intel and AMD + CPUs. + </para> + </listitem> + + </itemizedlist> + + <warning> + <para> + Do not run other hypervisors, either open source or commercial + virtualization products, together with &product-name;. While + several hypervisors can normally be + <emphasis>installed</emphasis> in parallel, do not attempt to + <emphasis>run</emphasis> several virtual machines from competing + hypervisors at the same time. &product-name; cannot track what + another hypervisor is currently attempting to do on the same + host, and especially if several products attempt to use hardware + virtualization features such as VT-x, this can crash the entire + host. + </para> + </warning> + + <para> + See <xref linkend="hwvirt-details"/> for a technical discussion of + hardware virtualization. + </para> + + </sect1> + + <sect1 id="hwvirt-details"> + + <title>Details About Hardware Virtualization</title> + + <para> + With Intel VT-x, there are two distinct modes of CPU operation: + VMX root mode and non-root mode. + </para> + + <itemizedlist> + + <listitem> + <para> + In root mode, the CPU operates much like older generations of + processors without VT-x support. There are four privilege + levels, called rings, and the same instruction set is + supported, with the addition of several virtualization + specific instruction. Root mode is what a host operating + system without virtualization uses, and it is also used by a + hypervisor when virtualization is active. + </para> + </listitem> + + <listitem> + <para> + In non-root mode, CPU operation is significantly different. + There are still four privilege rings and the same instruction + set, but a new structure called VMCS (Virtual Machine Control + Structure) now controls the CPU operation and determines how + certain instructions behave. Non-root mode is where guest + systems run. + </para> + </listitem> + + </itemizedlist> + + <para> + Switching from root mode to non-root mode is called "VM entry", + the switch back is "VM exit". The VMCS includes a guest and host + state area which is saved/restored at VM entry and exit. Most + importantly, the VMCS controls which guest operations will cause + VM exits. + </para> + + <para> + The VMCS provides fairly fine-grained control over what the guests + can and cannot do. For example, a hypervisor can allow a guest to + write certain bits in shadowed control registers, but not others. + This enables efficient virtualization in cases where guests can be + allowed to write control bits without disrupting the hypervisor, + while preventing them from altering control bits over which the + hypervisor needs to retain full control. The VMCS also provides + control over interrupt delivery and exceptions. + </para> + + <para> + Whenever an instruction or event causes a VM exit, the VMCS + contains information about the exit reason, often with + accompanying detail. For example, if a write to the CR0 register + causes an exit, the offending instruction is recorded, along with + the fact that a write access to a control register caused the + exit, and information about source and destination register. Thus + the hypervisor can efficiently handle the condition without + needing advanced techniques such as CSAM and PATM described above. + </para> + + <para> + VT-x inherently avoids several of the problems which software + virtualization faces. The guest has its own completely separate + address space not shared with the hypervisor, which eliminates + potential clashes. Additionally, guest OS kernel code runs at + privilege ring 0 in VMX non-root mode, obviating the problems by + running ring 0 code at less privileged levels. For example the + SYSENTER instruction can transition to ring 0 without causing + problems. Naturally, even at ring 0 in VMX non-root mode, any I/O + access by guest code still causes a VM exit, allowing for device + emulation. + </para> + + <para> + The biggest difference between VT-x and AMD-V is that AMD-V + provides a more complete virtualization environment. VT-x requires + the VMX non-root code to run with paging enabled, which precludes + hardware virtualization of real-mode code and non-paged + protected-mode software. This typically only includes firmware and + OS loaders, but nevertheless complicates VT-x hypervisor + implementation. AMD-V does not have this restriction. + </para> + + <para> + Of course hardware virtualization is not perfect. Compared to + software virtualization, the overhead of VM exits is relatively + high. This causes problems for devices whose emulation requires + high number of traps. One example is a VGA device in 16-color + mode, where not only every I/O port access but also every access + to the framebuffer memory must be trapped. + </para> + + </sect1> + + <sect1 id="gimproviders"> + + <title>Paravirtualization Providers</title> + + <para> + &product-name; enables the exposure of a paravirtualization + interface, to facilitate accurate and efficient execution of + software within a virtual machine. These interfaces require the + guest operating system to recognize their presence and make use of + them in order to leverage the benefits of communicating with the + &product-name; hypervisor. + </para> + + <para> + Most modern, mainstream guest operating systems, including Windows + and Linux, ship with support for one or more paravirtualization + interfaces. Hence, there is typically no need to install + additional software in the guest to take advantage of this + feature. + </para> + + <para> + Exposing a paravirtualization provider to the guest operating + system does not rely on the choice of host platforms. For example, + the <emphasis>Hyper-V</emphasis> paravirtualization provider can + be used for VMs to run on any host platform supported by + &product-name; and not just Windows. + </para> + + <para> + &product-name; provides the following interfaces: + </para> + + <itemizedlist> + + <listitem> + <para> + <emphasis role="bold">Minimal</emphasis>: Announces the + presence of a virtualized environment. Additionally, reports + the TSC and APIC frequency to the guest operating system. This + provider is mandatory for running any Mac OS X guests. + </para> + </listitem> + + <listitem> + <para> + <emphasis role="bold">KVM</emphasis>: Presents a Linux KVM + hypervisor interface which is recognized by Linux kernels + version 2.6.25 or later. &product-name;'s implementation + currently supports paravirtualized clocks and SMP spinlocks. + This provider is recommended for Linux guests. + </para> + </listitem> + + <listitem> + <para> + <emphasis role="bold">Hyper-V</emphasis>: Presents a Microsoft + Hyper-V hypervisor interface which is recognized by Windows 7 + and newer operating systems. &product-name;'s implementation + currently supports paravirtualized clocks, APIC frequency + reporting, guest debugging, guest crash reporting and relaxed + timer checks. This provider is recommended for Windows guests. + </para> + </listitem> + + </itemizedlist> + + </sect1> + + <sect1 id="nestedpaging"> + + <title>Nested Paging and VPIDs</title> + + <para> + In addition to normal hardware virtualization, your processor may + also support the following additional sophisticated techniques: + </para> + + <itemizedlist> + + <listitem> + <para> + Nested paging implements some memory management in hardware, + which can greatly accelerate hardware virtualization since + these tasks no longer need to be performed by the + virtualization software. + </para> + + <para> + With nested paging, the hardware provides another level of + indirection when translating linear to physical addresses. + Page tables function as before, but linear addresses are now + translated to "guest physical" addresses first and not + physical addresses directly. A new set of paging registers now + exists under the traditional paging mechanism and translates + from guest physical addresses to host physical addresses, + which are used to access memory. + </para> + + <para> + Nested paging eliminates the overhead caused by VM exits and + page table accesses. In essence, with nested page tables the + guest can handle paging without intervention from the + hypervisor. Nested paging thus significantly improves + virtualization performance. + </para> + + <para> + On AMD processors, nested paging has been available starting + with the Barcelona (K10) architecture. They now call it rapid + virtualization indexing (RVI). Intel added support for nested + paging, which they call extended page tables (EPT), with their + Core i7 (Nehalem) processors. + </para> + + <para> + If nested paging is enabled, the &product-name; hypervisor can + also use <emphasis>large pages</emphasis> to reduce TLB usage + and overhead. This can yield a performance improvement of up + to 5%. To enable this feature for a VM, you use the + <command>VBoxManage modifyvm --large-pages</command> command. + See <xref linkend="vboxmanage-modifyvm" />. + </para> + + <para> + If you have an Intel CPU with EPT, please consult + <xref linkend="sec-rec-cve-2018-3646" /> for security concerns + regarding EPT. + </para> + </listitem> + + <listitem> + <para> + On Intel CPUs, a hardware feature called Virtual Processor + Identifiers (VPIDs) can greatly accelerate context switching + by reducing the need for expensive flushing of the processor's + Translation Lookaside Buffers (TLBs). + </para> + + <para> + To enable these features for a VM, you use the + <command>VBoxManage modifyvm --vtx-vpid</command> and + <command>VBoxManage modifyvm --large-pages</command> commands. + See <xref linkend="vboxmanage-modifyvm" />. + </para> + </listitem> + + </itemizedlist> + + </sect1> + +</chapter> |