Nested paging virtualbox что это
Программное обеспечение в виртуальной машине выполняется непосредственно на процессоре главного компьютера, в то же время VirtualBox использует набор сложных методик, чтобы не допустить операций, которые вмешались бы в работу хоста.
Всякий раз, когда гость пытается сделать то, что может быть опасным для вашего компьютера и его данных, VirtualBox принимает меры. Для большого количества аппаратных средств, которые использует гость, VirtualBox моделирует определенную «виртуальную» среду, согласно конфигурации виртуальной машины. Например, если гость пытается обратиться к жесткому диску, VirtualBox переадресовывает эти запросы к объекту который вы сконфигурировали как виртуальный жесткий диск — обычно это файл образа диска на вашем хосте.
Существует два способа, которыми VirtualBox реализует «виртуализацию»: полностью программный способ или аппаратный используя специальные аппаратные возможности современных процессоров.
Новые процессоры Intel and AMD имеют поддержку так называемой «аппаратной виртуализации» . Она помогает программному обеспечению виртуализации, такому как VirtualBox, в прерывании потенциально опасных операций , которых операционная система гостя может пытаться выполнить.
Реализация этих функций различны в Intel и AMD. Intel назвала свою технологии VT-x , а AMD как AMD-V .
Примечание
На большинстве систем, сначало необходимо включить поддержку аппаратной виртуализацию в BIOS чтобы VirtualBox смог ее использовать
В отличии от других систем виртуализации, VirtualBox не требует, чтобы система хосте поддерживала аппаратную виртуализацию . VirtualBox поддерживает много гостевых операционных систем полностью в программном режиме виртуализации. Это означает, что Вы можете запускать виртуальные машины даже на менее современных процессорах, которые не поддерживают аппаратные средства виртуализации.
Вы можете указать для каждой виртуальной машины индивидуально, должен ли VirtualBox использовать программный или аппаратный способ виртуализации. До версии 2.2 программная виртуализация была значением по умолчанию; начинаясь с версии 2.2, VirtualBox устанавливает аппаратную виртуализацию по умолчанию для новых виртуальных машин, которых вы создаете. (Для уже существующих виртуальных машин смена режима автоматически не происходит, по причинам совместимости, и установленное значение по умолчанию может быть изменено для каждой виртуальной машины.)
Включение апаратной вертуализации необходимо только в двух случаях:
для некоторых редких гостевых ОС, например OS/2 , которые используют специфические команды процессора и которые не реализованы в VirtualBox
если вы хотите работать с 64 битовыми гостевыми ОС (начиная с VirtualBox версии 2.0), большинство 64 битных CPU поддерживают аппаратную виртуализацию — исключая старшие линейки процессоров Intel Celeron и AMD Opteron .
Установка аппаратной виртуализации по умолчанию, вызвана тем что, технологии виртуализации Intel, ADM и VirtualBox значительно улучшились, и аппаратная виртуализация в большинстве случаях производительнее программной.
Предупреждение
Не работайте одновременно с другими гипервизорами (программами исполнения виртуальных машин) (open-source or commercial virtualization products) с VirtualBox! Несколько гипервизоров могут обычно устанавливаться параллельно на одной системе, но не пытайтесь выполнить несколько виртуальных машин на различных гипервизоров в одно и то же время. VirtualBox не может проследить за тем, что другой гипервизор пытается сделать на том же самой системе, и особенно если они одновременно пытаются использовать возможности аппаратной виртуализации, такие как VT-X, что может превести к краху всей системы.
Кроме «базовой» аппаратной виртуализации, ваш процессор может поддерживать дополнительные технологии: [1]
Наиболее новая технология «nested paging» позволяет управлять памятью хоста, что позволяет усилить производительность , т.к. не требуется программное управление памятью.
На AMD процессорах, nested paging стала доступна начиная с архитектуры Barcelona (K10) ; Intel добавила поддержку nested paging, которую она назвала «extended page tables» (EPT), в свих процессорах Core i7 (Nehalem).
Технология Nested paging не устанавливается по умолчанию, но она может быть установлена отдельно для каждой ВМ.
Если ваш компьютер поддерживает nested paging (AMD-V) or EPT (VT-x), то вы можете получить значительный прирост производительности используя эту технологию.
Другая аппаратная возможность называется «Virtual Processor Identifiers» (VPIDs) позволяет значительно ускорить переключение контекста Translation Lookaside Buffers (TLBs) процессора, уменьшая количество операции записей на диск . Чтобы использовать эту возможность вы должны использовать командную строку; см Section 8.5, “VBoxManage modifyvm”.
[1] Поддержка AMD nested paging добавлена в VirtualBox 2.0 ; поддержка Intel EPT и VPIDs добавлена в версии 2.1.
10.7. Nested paging and VPIDs
A newer feature called «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.
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.
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.
On AMD processors, nested paging has been available starting with the Barcelona (K10) architecture — they call it now «rapid virtualization indexing» (RVI). Intel added support for nested paging, which they call «extended page tables» (EPT), with their Core i7 (Nehalem) processors.
If nested paging is enabled, the VirtualBox hypervisor can also use large pages to reduce TLB usage and overhead. This can yield a performance improvement of up to 5%. To enable this feature for a VM, you need to use the VBoxManage modifyvm —largepages command; see Section 8.8, “VBoxManage modifyvm”.
On Intel CPUs, another 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).
To enable these features for a VM, you need to use the VBoxManage modifyvm —vtxvpid and —largepages commands; see Section 8.8, “VBoxManage modifyvm”.
[47] VirtualBox 2.0 added support for AMD’s nested paging; support for Intel’s EPT and VPIDs was added with version 2.1.
Nested paging virtualbox что это
Table of Contents
The contents of this chapter are not required to use VirtualBox successfully. The following is provided as additional information for readers who are more familiar with computer architecture and technology and wish to find out more about how VirtualBox works «under the hood».
Where VirtualBox stores its files
In VirtualBox, a virtual machine and its settings are described in a virtual machine settings file in XML format. In addition, most virtual machine have one or more virtual hard disks, which are typically represented by disk images (e.g. in VDI format). Where all these files are stored depends on which version of VirtualBox created the machine.
Machines created by VirtualBox version 4.0 or later
Starting with version 4.0, by default, each virtual machine has one directory on your host computer where all the files of that machine are stored — the XML settings file (with a .vbox file extension) and its disk images.
By default, this «machine folder» is placed in a common folder called «VirtualBox VMs», which VirtualBox creates in the current system user’s home directory. The location of this home directory depends on the conventions of the host operating system:
On Windows, this is %HOMEDRIVE%%HOMEPATH% ; typically something like C:\Documents and Settings\Username\ .
On Mac OS X, this is /Users/username .
On Linux and Solaris, this is /home/username .
For simplicity, we will abbreviate this as $HOME below. Using that convention, the common folder for all virtual machines is $HOME/VirtualBox VMs .
As an example, when you create a virtual machine called «Example VM», you will find that VirtualBox creates
the folder $HOME/VirtualBox VMs/Example VM/ and, in that folder,
the settings file Example VM.vbox and
the virtual disk image Example VM.vdi .
This is the default layout if you use the «Create new virtual machine» wizard as described in the section called “Creating your first virtual machine”. Once you start working with the VM, additional files will show up: you will find log files in a subfolder called Logs , and once you have taken snapshots, they will appear in a Snapshots subfolder. For each VM, you can change the location of its snapsnots folder in the VM settings.
You can change the default machine folder by selecting «Preferences» from the «File» menu in the VirtualBox main window. Then, in the window that pops up, click on the «General» tab. Alternatively, use VBoxManage setproperty machinefolder ; see the section called “VBoxManage setproperty”.
Machines created by VirtualBox versions before 4.0
If you have upgraded to VirtualBox 4.0 from an earlier version of VirtualBox, you probably have settings files and disks in the earlier file system layout.
Before version 4.0, VirtualBox separated the machine settings files from virtual disk images. The machine settings files had an .xml file extension and resided in a folder called «Machines» under the global VirtualBox configuration directory (see the next section). So, for example, on Linux, this was the hidden $HOME/.VirtualBox/Machines directory. The default hard disks folder was called «HardDisks» and resided in the .VirtualBox folder as well. Both locations could be changed by the user in the global preferences. (The concept of a «default hard disk folder» has been abandoned with VirtualBox 4.0, since disk images now reside in each machine’s folder by default.)
The old layout had several severe disadvantages.
It was very difficult to move a virtual machine from one host to another because the files involved did not reside in the same folder. In addition, the virtual media of all machines were registered with a global registry in the central VirtualBox settings file ( $HOME/.VirtualBox/VirtualBox.xml ).
To move a machine to another host, it was therefore not enough to move the XML settings file and the disk images (which were in different locations), but the hard disk entries from the global media registry XML had to be meticulously copied as well, which was close to impossible if the machine had snapshots and therefore differencing images.
Storing virtual disk images, which can grow very large, under the hidden .VirtualBox directory (at least on Linux and Solaris hosts) made many users wonder where their disk space had gone.
Whereas new VMs created with VirtualBox 4.0 or later will conform to the new layout, for maximum compatibility, old VMs are not converted to the new layout. Otherwise machine settings would be irrevocably broken if a user downgraded from 4.0 back to an older version of VirtualBox.
Global configuration data
In addition to the files of the virtual machines, VirtualBox maintains global configuration data. On Windows, Linux and Solaris, this is in $HOME/.VirtualBox (which makes it hidden on Linux and Solaris), whereas on a Mac this resides in $HOME/Library/VirtualBox .
VirtualBox creates this configuration directory automatically if necessary. Optionally, you can supply an alternate configuration directory by setting the VBOX_USER_HOME environment variable. (Since the global VirtualBox.xml settings file points to all other configuration files, this allows for switching between several VirtualBox configurations entirely.)
Most importantly, in this directory, VirtualBox stores its global settings file, another XML file called VirtualBox.xml . This includes global configuration options and the list of registered virtual machines with pointers to their XML settings files. (Neither the location of this file nor its directory has changed with VirtualBox 4.0.)
Before VirtualBox 4.0, all virtual media (disk image files) were also contained in a global registry in this settings file. For compatibility, this media registry still exists if you upgrade VirtualBox and there are media from machines which were created with a version before 4.0. If you have no such machines, then there will be no global media registry; with VirtualBox 4.0, each machine XML file has its own media registry.
Also before VirtualBox 4.0, the default «Machines» folder and the default «HardDisks» folder resided under the VirtualBox configuration directory (e.g. $HOME/.VirtualBox/Machines on Linux). If you are upgrading from a VirtualBox version before 4.0, files in these directories are not automatically moved in order not to break backwards compatibility.
Summary of 4.0 configuration changes
Table�10.1.�ignoreme
| � | Before 4.0 | 4.0 or above |
| Default machines folder | $HOME/.VirtualBox/Machines | $HOME/VirtualBox VMs |
| Default disk image location | $HOME/.VirtualBox/HardDisks | In each machine’s folder |
| Machine settings file extension | .xml | .vbox |
| Media registry | Global VirtualBox.xml file | Each machine settings file |
| Media registration | Explicit open/close required | Automatic on attach |
VirtualBox XML files
VirtualBox uses XML for both the machine settings files and the global configuration file, VirtualBox.xml .
All VirtualBox XML files are versioned. When a new settings file is created (e.g. because a new virtual machine is created), VirtualBox automatically uses the settings format of the current VirtualBox version. These files may not be readable if you downgrade to an earlier version of VirtualBox. However, when VirtualBox encounters a settings file from an earlier version (e.g. after upgrading VirtualBox), 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 VirtualBox. [36] In such cases, VirtualBox backs up the old settings file in the virtual machine’s configuration directory. If you need to go back to the earlier version of VirtualBox, then you will need to manually copy these backup files back.
We intentionally do not document the specifications of the VirtualBox 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. VirtualBox provides complete access to its configuration data through its the VBoxManage command line tool (see Chapter�8, VBoxManage) and its API (see Chapter�11, VirtualBox programming interfaces).
VirtualBox executables and components
VirtualBox was designed to be modular and flexible. When the VirtualBox graphical user interface (GUI) is opened and a VM is started, at least three processes are running:
VBoxSVC , the VirtualBox service process which always runs in the background. This process is started automatically by the first VirtualBox client process (the GUI, VBoxManage , VBoxHeadless , the web service or others) and exits a short time after the last client exits. The service is responsible for bookkeeping, maintaining the state of all VMs, and for providing communication between VirtualBox components. This communication is implemented via COM/XPCOM.
When we refer to «clients» here, we mean the local clients of a particular VBoxSVC server process, not clients in a network. VirtualBox 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.
The GUI process, VirtualBox , a client application based on the cross-platform Qt library. When started without the —startvm option, this application acts as the VirtualBox manager, displaying the VMs and their settings. It then communicates settings and state changes to VBoxSVC and also reflects changes effected through other means, e.g., VBoxManage .
If the VirtualBox client application is started with the —startvm 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.
Any VirtualBox front-end (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.
The VirtualBox GUI application is only one of several available front ends (clients). The complete list shipped with VirtualBox is:
VirtualBox , the Qt front end implementing the manager and running VMs;
VBoxManage , a less user-friendly but more powerful alternative, described in Chapter�8, VBoxManage.
VBoxSDL , a simple graphical front end based on the SDL library; see the section called “VBoxSDL, the simplified VM displayer”.
VBoxHeadless , a VM front end which does not directly provide any video output and keyboard/mouse input, but allows redirection via VirtualBox Remote Desktop Extension; see the section called “VBoxHeadless, the remote desktop server”.
vboxwebsrv , the VirtualBox web service process which allows for controlling a VirtualBox host remotely. This is described in detail in the VirtualBox Software Development Kit (SDK) reference; please see Chapter�11, VirtualBox programming interfaces for details.
The VirtualBox Python shell, a Python alternative to VBoxManage. This is also described in the SDK reference.
Internally, VirtualBox consists of many more or less separate components. You may encounter these when analyzing VirtualBox internal error messages or log files. These include:
IPRT, a portable runtime library which abstracts file access, threading, string manipulation, etc. Whenever VirtualBox accesses host operating features, it does so through this library for cross-platform portability.
VMM (Virtual Machine Monitor), the heart of the hypervisor.
EM (Execution Manager), controls execution of guest code.
REM (Recompiled Execution Monitor), provides software emulation of CPU instructions.
TRPM (Trap Manager), intercepts and processes guest traps and exceptions.
HWACCM (Hardware Acceleration Manager), provides support for VT-x and AMD-V.
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 VirtualBox without having to change VirtualBox itself.
PGM (Page Manager), a component controlling guest paging.
PATM (Patch Manager), patches guest code to improve and speed up software virtualization.
TM (Time Manager), handles timers and all aspects of time inside guests.
CFGM (Configuration Manager), provides a tree structure which holds configuration settings for the VM and all emulated devices.
SSM (Saved State Manager), saves and loads VM state.
VUSB (Virtual USB), a USB layer which separates emulated USB controllers from the controllers on the host and from USB devices; this also enables remote USB.
DBGF (Debug Facility), a built-in VM debuger.
VirtualBox 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.
Guest Additions for various guest operating systems. This is code that is installed from within a virtual machine; see Chapter�4, Guest Additions.
The «Main» component is special: it ties all the above bits together and is the only public API that VirtualBox 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 VirtualBox Main API can rely on the fact that it is always well-tested and that all capabilities of VirtualBox are fully exposed. It is this API that is described in the VirtualBox SDK mentioned above (again, see Chapter�11, VirtualBox programming interfaces).
Hardware vs. software virtualization
VirtualBox allows 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, VirtualBox steps in and takes action. In particular, for lots of hardware that the guest believes to be accessing, VirtualBox simulates a certain «virtual» environment according to how you have configured a virtual machine. For example, when the guest attempts to access a hard disk, VirtualBox redirects these requests to whatever you have configured to be the virtual machine’s virtual hard disk — normally, an image file on your host.
Unfortunately, the x86 platform was never designed to be virtualized. Detecting situations in which VirtualBox needs to take control over the guest code that is executing, as described above, is difficult. There are two ways in which to achive this:
Since 2006, Intel and AMD processors have had support for so-called «hardware virtualization» . This means that these processors can help VirtualBox 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.
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.
On many systems, the hardware virtualization features first need to be enabled in the BIOS before VirtualBox can use them.
As opposed to other virtualization software, for many usage scenarios, VirtualBox does not require hardware virtualization features to be present. Through sophisticated techniques, VirtualBox virtualizes many guest operating systems entirely in software . This means that you can run virtual machines even on older processors which do not support hardware virtualization.
Even though VirtualBox does not always require hardware virtualization, enabling it is required in the following scenarios:
Certain rare guest operating systems like OS/2 make use of very esoteric processor instructions that are not supported with our software virtualization. For virtual machines that are configured to contain such an operating system, hardware virtualization is enabled automatically.
VirtualBox’s 64-bit guest support (added with version 2.0) and multiprocessing (SMP, added with version 3.0) both require hardware virtualization to be enabled. (This is not much of a limitation since the vast majority of today’s 64-bit and multicore CPUs ship with hardware virtualization anyway; the exceptions to this rule are e.g. older Intel Celeron and AMD Opteron CPUs.)
Warning
Do not run other hypervisors (open-source or commercial virtualization products) together with VirtualBox! While several hypervisors can normally be installed in parallel, do not attempt to run several virtual machines from competing hypervisors at the same time. VirtualBox 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. Also, within VirtualBox, you can mix software and hardware virtualization when running multiple VMs. In certain cases a small performance penalty will be unavoidable when mixing VT-x and software virtualization VMs. We recommend not mixing virtualization modes if maximum performance and low overhead are essential. This does not apply to AMD-V.
Details about software virtualization
Implementing virtualization on x86 CPUs with no hardware virtualization support is an extraordinarily complex task because the CPU architecture was not designed to be virtualized. The problems can usually be solved, but at the cost of reduced performance. Thus, there is a constant clash between virtualization performance and accuracy.
The x86 instruction set was originally designed in the 1970s and underwent significant changes with the addition of protected mode in the 1980s with the 286 CPU architecture and then again with the Intel 386 and its 32-bit architecture. Whereas the 386 did have limited virtualization support for real mode operation (V86 mode, as used by the «DOS Box» of Windows 3.x and OS/2 2.x), no support was provided for virtualizing the entire architecture.
In theory, software virtualization is not overly complex. In addition to the four privilege levels («rings») provided by the hardware (of which typically only two are used: ring 0 for kernel mode and ring 3 for user mode), one needs to differentiate between «host context» and «guest context».
In «host context», everything is as if no hypervisor was active. This might be the active mode if another application on your host has been scheduled CPU time; in that case, there is a host ring 3 mode and a host ring 0 mode. The hypervisor is not involved.
In «guest context», however, a virtual machine is active. So long as the guest code is running in ring 3, this is not much of a problem since a hypervisor can set up the page tables properly and run that code natively on the processor. The problems mostly lie in how to intercept what the guest’s kernel does.
There are several possible solutions to these problems. One approach is full software emulation, usually involving recompilation. That is, all code to be run by the guest is analyzed, transformed into a form which will not allow the guest to either modify or see the true state of the CPU, and only then executed. This process is obviously highly complex and costly in terms of performance. (VirtualBox contains a recompiler based on QEMU which can be used for pure software emulation, but the recompiler is only activated in special situations, described below.)
Another possible solution is paravirtualization, in which only specially modified guest OSes are allowed to run. This way, most of the hardware access is abstracted and any functions which would normally access the hardware or privileged CPU state are passed on to the hypervisor instead. Paravirtualization can achieve good functionality and performance on standard x86 CPUs, but it can only work if the guest OS can actually be modified, which is obviously not always the case.
VirtualBox chooses a different approach. When starting a virtual machine, through its ring-0 support kernel driver, VirtualBox has set up the host system so that it can run most of the guest code natively, but it has inserted itself at the «bottom» of the picture. It can then assume control when needed — if a privileged instruction is executed, the guest traps (in particular because an I/O register was accessed and a device needs to be virtualized) or external interrupts occur. VirtualBox may then handle this and either route a request to a virtual device or possibly delegate handling such things to the guest or host OS. In guest context, VirtualBox can therefore be in one of three states:
Guest ring 3 code is run unmodified, at full speed, as much as possible. The number of faults will generally be low (unless the guest allows port I/O from ring 3, something we cannot do as we don’t want the guest to be able to access real ports). This is also referred to as «raw mode», as the guest ring-3 code runs unmodified.
For guest code in ring 0, VirtualBox employs a nasty trick: it actually reconfigures the guest so that its ring-0 code is run in ring 1 instead (which is normally not used in x86 operating systems). As a result, when guest ring-0 code (actually running in ring 1) such as a guest device driver attempts to write to an I/O register or execute a privileged instruction, the VirtualBox hypervisor in «real» ring 0 can take over.
The hypervisor (VMM) can be active. Every time a fault occurs, VirtualBox looks at the offending instruction and can relegate it to a virtual device or the host OS or the guest OS or run it in the recompiler.
In particular, the recompiler is used when guest code disables interrupts and VirtualBox cannot figure out when they will be switched back on (in these situations, VirtualBox actually analyzes the guest code using its own disassembler). Also, certain privileged instructions such as LIDT need to be handled specially. Finally, any real-mode or protected-mode code (e.g. BIOS code, a DOS guest, or any operating system startup) is run in the recompiler entirely.
Unfortunately this only works to a degree. Among others, the following situations require special handling:
Running ring 0 code in ring 1 causes a lot of additional instruction faults, as ring 1 is not allowed to execute any privileged instructions (of which guest’s ring-0 contains plenty). With each of these faults, the VMM must step in and emulate the code to achieve the desired behavior. While this works, emulating thousands of these faults is very expensive and severely hurts the performance of the virtualized guest.
There are certain flaws in the implementation of ring 1 in the x86 architecture that were never fixed. Certain instructions that should trap in ring 1 don’t. This affect for example the LGDT/SGDT, LIDT/SIDT, or POPF/PUSHF instruction pairs. Whereas the «load» operation is privileged and can therefore be trapped, the «store» instruction always succeed. If the guest is allowed to execute these, it will see the true state of the CPU, not the virtualized state. The CPUID instruction also has the same problem.
A hypervisor typically needs to reserve some portion of the guest’s address space (both linear address space and selectors) for its own use. This is not entirely transparent to the guest OS and may cause clashes.
The SYSENTER instruction (used for system calls) executed by an application running in a guest OS always transitions to ring 0. But that is where the hypervisor runs, not the guest OS. In this case, the hypervisor must trap and emulate the instruction even when it is not desirable.
The CPU segment registers contain a «hidden» descriptor cache which is not software-accessible. The hypervisor cannot read, save, or restore this state, but the guest OS may use it.
Some resources must (and can) be trapped by the hypervisor, but the access is so frequent that this creates a significant performance overhead. An example is the TPR (Task Priority) register in 32-bit mode. Accesses to this register must be trapped by the hypervisor, but certain guest operating systems (notably Windows and Solaris) write this register very often, which adversely affects virtualization performance.
To fix these performance and security issues, VirtualBox contains a Code Scanning and Analysis Manager (CSAM), which disassembles guest code, and the Patch Manager (PATM), which can replace it at runtime.
Before executing ring 0 code, CSAM scans it recursively to discover problematic instructions. PATM then performs in-situ patching, i.e. it replaces the instruction with a jump to hypervisor memory where an integrated code generator has placed a more suitable implementation. In reality, this is a very complex task as there are lots of odd situations to be discovered and handled correctly. So, with its current complexity, one could argue that PATM is an advanced in-situ recompiler.
In addition, every time a fault occurs, VirtualBox analyzes the offending code to determine if it is possible to patch it in order to prevent it from causing more faults in the future. This approach works well in practice and dramatically improves software virtualization performance.
Details about hardware virtualization
With Intel VT-x, there are two distinct modes of CPU operation: VMX root mode and non-root mode.
In root mode, the CPU operates much like older generations of processors without VT-x support. There are four privilege levels («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.
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.
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.
The VMCS provides fairly fine-grained control over what the guests can and can’t 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.
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.
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.
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.
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 the VGA device in 16-color modes, where not only every I/O port access but also every access to the framebuffer memory must be trapped.
Nested paging and VPIDs
In addition to «plain» hardware virtualization, your processor may also support additional sophisticated techniques: [37]
A newer feature called «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.
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.
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.
On AMD processors, nested paging has been available starting with the Barcelona (K10) architecture — they call it now «rapid virtualization indexing» (RVI). Intel added support for nested paging, which they call «extended page tables» (EPT), with their Core i7 (Nehalem) processors.
If nested paging is enabled, the VirtualBox hypervisor can also use large pages to reduce TLB usage and overhead. This can yield a performance improvement of up to 5%. To enable this feature for a VM, you need to use the VBoxManage modifyvm —largepages command; see the section called “VBoxManage modifyvm”.
On Intel CPUs, another 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).
To enable these features for a VM, you need to use the VBoxManage modifyvm —vtxvpids and —largepages commands; see the section called “VBoxManage modifyvm”.
[36] As an example, before VirtualBox 3.1, it was only possible to enable or disable a single DVD drive in a virtual machine. If it was enabled, then it would always be visible as the secondary master of the IDE controller. With VirtualBox 3.1, DVD drives can be attached to arbitrary slots of arbitrary controllers, so they could be the secondary slave of an IDE controller or in a SATA slot. If you have a machine settings file from an earlier version and upgrade VirtualBox to 3.1 and then move the DVD drive from its default position, this cannot be expressed in the old settings format; the XML machine file would get written in the new format, and a backup file of the old format would be kept.
[37] VirtualBox 2.0 added support for AMD’s nested paging; support for Intel’s EPT and VPIDs was added with version 2.1.
Nested paging virtualbox что это
Oracle® VM VirtualBox
Administrator’s Guide for Release 6.0
- Preface
- Remote Virtual Machines
- Remote Display (VRDP Support)
- Common Third-Party RDP Viewers
- VBoxHeadless, the Remote Desktop Server
- Step by Step: Creating a Virtual Machine on a Headless Server
- Remote USB
- RDP Authentication
- RDP Encryption
- Multiple Connections to the VRDP Server
- Multiple Remote Monitors
- VRDP Video Redirection
- VRDP Customization
- Automated Guest Logins
- Automated Windows Guest Logins
- Automated Linux and UNIX Guest Logins
- Oracle VM VirtualBox Greeter for Ubuntu/LightDM
- Automated Windows System Preparation
- Manual Setup of Selected Guest Services on Linux
- Guest Graphics and Mouse Driver Setup in Depth
- Using a Host Webcam in the Guest
- Windows Hosts
- Mac OS X Hosts
- Linux and Oracle Solaris Hosts
- Custom VESA Resolutions
- Configuring the Maximum Resolution of Guests When Using the Graphical Frontend
- Using a Raw Host Hard Disk From a Guest
- Access to Entire Physical Hard Disk
- Access to Individual Physical Hard Disk Partitions
- Configuring the Address of a NAT Network Interface
- Configuring the Boot Server (Next Server) of a NAT Network Interface
- Tuning TCP/IP Buffers for NAT
- Binding NAT Sockets to a Specific Interface
- Enabling DNS Proxy in NAT Mode
- Using the Host’s Resolver as a DNS Proxy in NAT Mode
- User-Defined Host Name Resolving
- Configuring the Guest Time Stamp Counter (TSC) to Reflect Guest Execution
- Accelerate or Slow Down the Guest Clock
- Tuning the Guest Additions Time Synchronization Parameters
- Disabling the Guest Additions Time Synchronization
- Customizing the VirtualBox Manager
- VM Selector Customization
- Configure VM Selector Menu Entries
- Configure VM Window Menu Entries
- Configure VM Window Status Bar Entries
- Configure VM Window Visual Modes
- Host Key Customization
- Action when Terminating the VM
- Default Action when Terminating the VM
- Action for Handling a Guru Meditation
- Configuring Automatic Mouse Capturing
- Requesting Legacy Full-Screen Mode
- Removing Certain Modes of Networking From the GUI
- Linux: Starting the Web Service With init
- Oracle Solaris: Starting the Web Service With SMF
- Mac OS X: Starting the Web Service With launchd
- Memory Ballooning Control
- Host Isolation Detection
- More Information
- Linux: Starting the Watchdog Service With init
- Oracle Solaris: Starting the Watchdog Service With SMF
- Linux: Starting the Autostart Service With init
- Oracle Solaris: Starting the Autostart Service With SMF
- Mac OS X: Starting the Autostart Service With launchd
- Windows: Starting the Autostart Service With a Windows service
- Limitations of Disk Encryption
- Encrypting Disk Images
- Starting a VM with Encrypted Images
- Decrypting Encrypted Images
- Hyper-V Debug Options
- Setting up Windows Guests for Debugging with the Hyper-V Paravirtualization Provider
- Setting up USB/IP Support on a Linux System
- Security Considerations
- Synopsis
- Description
- VISO file format
- File specifications and —name-setup
- General
- Namespaces
- File Attributes
- Booting
- String properties (applied to active namespaces only)
- Compatibility:
- VISO Specific:
- Testing (not applicable to VISO):
- Where Oracle VM VirtualBox Stores its Files
- The Machine Folder
- Global Settings
- Summary of Configuration Data Locations
- Oracle VM VirtualBox XML Files
- Procedures and Tools
- Categorizing and Isolating Problems
- Collecting Debugging Information
- Using the VBoxBugReport Command to Collect Debug Information Automatically
- The Built-In VM Debugger
- VM Core Format
- Guest Shows IDE/SATA Errors for File-Based Images on Slow Host File System
- Responding to Guest IDE/SATA Flush Requests
- Performance Variation with Frequency Boosting
- Frequency Scaling Effect on CPU Usage
- Inaccurate Windows CPU Usage Reporting
- Poor Performance Caused by Host Power Management
- GUI: 2D Video Acceleration Option is Grayed Out
- No USB 3.0 Support in Windows 7 Guests
- Windows Bluescreens After Changing VM Configuration
- Windows 0x101 Bluescreens with SMP Enabled (IPI Timeout)
- Windows 2000 Installation Failures
- How to Record Bluescreen Information from Windows Guests
- No Networking in Windows Vista Guests
- Windows Guests may Cause a High CPU Load
- Long Delays When Accessing Shared Folders
- USB Tablet Coordinates Wrong in Windows 98 Guests
- Windows Guests are Removed From an Active Directory Domain After Restoring a Snapshot
- Windows 3.x Limited to 64 MB RAM
- Linux Guests May Cause a High CPU load
- Buggy Linux 2.6 Kernel Versions
- Shared Clipboard, Auto-Resizing, and Seamless Desktop in X11 Guests
- Certain Oracle Solaris 10 Releases May Take a Long Time to Boot with SMP
- VBoxSVC Out-of-Process COM Server Issues
- CD and DVD Changes Not Recognized
- Sluggish Response When Using Microsoft RDP Client
- Running an iSCSI Initiator and Target on a Single System
- Bridged Networking Adapters Missing
- Host-Only Networking Adapters Cannot be Created
- Linux Kernel Module Refuses to Load
- Linux Host CD or DVD Drive Not Found
- Linux Host CD or DVD Drive Not Found (Older Distributions)
- Linux Host Floppy Not Found
- Strange Guest IDE Error Messages When Writing to CD or DVD
- VBoxSVC IPC Issues
- USB Not Working
- PAX/grsec Kernels
- Linux Kernel vmalloc Pool Exhausted
- Cannot Start VM, Not Enough Contiguous Memory
- General Security Principles
- Secure Installation and Configuration
- Installation Overview
- Post Installation Configuration
- The Security Model
- Secure Configuration of Virtual Machines
- Networking
- VRDP Remote Desktop Authentication
- Clipboard
- Shared Folders
- 3D Graphics Acceleration
- CD/DVD Passthrough
- USB Passthrough
- CVE-2018-3646
- Disable Nested Paging
- Flushing the Level 1 Data Cache
- Buffer Overwriting and Disabling Hyper-Threading
- Experimental Features
- Known Issues
- Third-Party Materials
- Third-Party Licenses
- GNU General Public License (GPL)
- GNU Lesser General Public License (LGPL)
- Mozilla Public License (MPL)
- MIT License
- X Consortium License (X11)
- zlib License
- OpenSSL License
- Slirp License
- liblzf License
- libpng License
- lwIP License
- libxml License
- libxslt Licenses
- gSOAP Public License Version 1.3a
- Chromium Licenses
- Main License
- COPYRIGHT.LLNL File
- COPYRIGHT.REDHAT File
- Introduction
- Legal Terms
3.7. Nested Paging and VPIDs
In addition to normal hardware virtualization, your processor may also support the following additional sophisticated techniques:
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.
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.
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.
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.
If nested paging is enabled, the Oracle VM VirtualBox hypervisor can also use large pages 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 VBoxManage modifyvm —largepages command. See VBoxManage modifyvm.
If you have an Intel CPU with EPT, please consult Section 6.4.1, “CVE-2018-3646” for security concerns regarding EPT.
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).
To enable these features for a VM, you use the VBoxManage modifyvm —vtxvpid and VBoxManage modifyvm —largepages commands. See VBoxManage modifyvm.
Copyright © 2004, 2020 Oracle and/or its affiliates. All rights reserved. Legal Notices
- Remote Display (VRDP Support)