Changes between Version 17 and Version 18 of VirtualBox architecture
- Timestamp:
- Nov 16, 2006 6:00:55 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
VirtualBox architecture
v17 v18 1 = The VirtualBox architecture =1 = The !VirtualBox architecture = 2 2 3 3 [wiki:"Virtualization"] is, by nature, extraordinarily complex, especially so on x86 hardware. Understanding the !VirtualBox source code therefore requires, at least for some components, a great deal of understanding about the details of the x86 architecture as well as great knowledge about the implementations of the host and guest platforms involved. … … 7 7 == The !VirtualBox processes: a bird's eye view == 8 8 9 When you start the !VirtualBox graphical user interface (GUI), at least one extra process gets started along the way -- the !VirtualBox "service" , normally dubbed`VBoxSVC`.9 When you start the !VirtualBox graphical user interface (GUI), at least one extra process gets started along the way -- the !VirtualBox "service" process `VBoxSVC`. 10 10 11 11 Once you start a virtual machine (VM) from the GUI, you have two windows (the main window and the VM), but three processes running. Looking at your system from Task Manager (on Windows) or some system monitor (on Linux), you will see these: … … 17 17 (On Linux, there's another daemon process called `VBoxXPCOMIPCD` which is necessary for our XPCOM implementation to work. We will ignore this for now; see [wiki:"COM-XPCOM interoperability"] for details.) 18 18 19 To the host operating system (OS), the VM that runs "inside" the second window looks like just another Qt process. !VirtualBox is very well behaved in that respect: it pretty much takes over control over a large part of your computer, executing a complete OS with its own set of guest processes, drivers, and devices inside this VM process, but the host OS does not notice much of this. Whatever the VM does, it's just another process in your host OS.19 To the host operating system (OS), the VM that runs "inside" the second window looks like an ordinary program. !VirtualBox is very well behaved in that respect: it pretty much takes over control over a large part of your computer, executing a complete OS with its own set of guest processes, drivers, and devices inside this VM process, but the host OS does not notice much of this. Whatever the VM does, it's just another process in your host OS. 20 20 21 21 We therefore have two sorts of encapsulation in place with the various !VirtualBox files and processes: … … 35 35 * A "plain" GUI based on [http://www.libsdl.org/index.php SDL], with fewer fancy features than the Qt GUI. This is useful for business use as well as testing during development. To control the VMs, you will then use `VBoxManage`. 36 36 37 * A nRemote Desktop Protocol (RDP) server, which is console-only and produces no graphical output on the host, but allows remote computers to connect to it. This is especially useful for enterprises who want to consolidate their client PCs onto just a few servers. The client PCs are then merely displaying RDP data produced by the various RDP server processes on a few big servers, which virtualize the "real" client PCs. (The RDP server is not part of !VirtualBox OSE, but is available with the full version; see the [wiki:"Editions"] page for details.)37 * A Remote Desktop Protocol (RDP) server, which is console-only and produces no graphical output on the host, but allows remote computers to connect to it. This is especially useful for enterprises who want to consolidate their client PCs onto just a few servers. The client PCs are then merely displaying RDP data produced by the various RDP server processes on a few big servers, which virtualize the "real" client PCs. (The RDP server is not part of !VirtualBox OSE, but is available with the full version; see the [wiki:"Editions"] page for details.) 38 38 39 39 == Inside a virtual machine == … … 49 49 * for any real-mode code (e.g. BIOS code, a DOS guest, or any operating system startup). 50 50 3. Your CPU can be '''running guest ring-3 code natively''' (within the ring-3 host VM process). With !VirtualBox, we call this "raw ring 3". This is, of course, the most efficient way to run the guest, and hopefully we don't leave this mode too often. The more we do, the slower the VM is compared to a native OS, because all context switches are very expensive. 51 4. Your CPU can be '''running guest ring-0 code natively.''' Here is where things get hairy: The guest only ''thinks'' it's running ring-0 code, but !VirtualBox has patched the guest OS to instead enter ring 1 (which is normally unused with x86 operating systems).51 4. Your CPU can be '''running guest ring-0 code natively.''' Here is where things get hairy: The guest only ''thinks'' it's running ring-0 code, but !VirtualBox has fooled the guest OS to instead enter ring 1 (which is normally unused with x86 operating systems). 52 52 53 53 Also, in the !VirtualBox source code, you will find lots of references to "host context" or "guest context". Essentially, these mean: 54 54 55 * '''Host context (HC)''' means that the host OS is in control of everything including virtual memory. In the !VirtualBox sources, the term "HC" will normally refer to the host's ring-3 context only. We only use host ring-0 (R0) context with our new Intel V MX(Vanderpool) support, which we'll leave out of the picture for now (but see below).55 * '''Host context (HC)''' means that the host OS is in control of everything including virtual memory. In the !VirtualBox sources, the term "HC" will normally refer to the host's ring-3 context only. We only use host ring-0 (R0) context with our new Intel VT-x (Vanderpool) support, which we'll leave out of the picture for now (but see below). 56 56 57 57 * '''Guest context (GC)''' means that !VirtualBox has set up CPU & memory exactly the way the guest expects, but has inserted itself at the "bottom" of the picture, so that !VirtualBox gains control ''first'' for any privileged instructions executed, guest trap or external interrupts, before !VirtualBox may then possibly delegate handling such things to the host OS. So, in the guest context, we have … … 68 68 * when switching from host ring-3 to guest context; 69 69 70 * enable or disable V anderpooletc. support.70 * enable or disable VT-x etc. support. 71 71 72 Most importantly, the host's ring-0 driver does ''not'' mess with your OS's scheduling or process management. The entire guest OS, including its own hund ereds of processes, is only scheduled when the host OS gives the VM process a timeslice.72 Most importantly, the host's ring-0 driver does ''not'' mess with your OS's scheduling or process management. The entire guest OS, including its own hundreds of processes, is only scheduled when the host OS gives the VM process a timeslice. 73 73 74 74 75 == Intel V MX("Vanderpool") support ==75 == Intel VT-x ("Vanderpool") support == 76 76 77 With its latest processors, Intel has introduced hardware virtualization support, which they call "Vanderpool", "IVT", "VT-x", or "VMX" (for "virtual machine extensions"). Weuse the term "VMX". A thorough explanation of this architecture can be found on [http://www.intel.com/technology/itj/2006/v10i3/1-hardware/5-architecture.htm Intel's pages], but as a summary, with these extensions, a processor always operates in one of the following two modes:77 With its latest processors, Intel has introduced hardware virtualization support, which they call "Vanderpool", "IVT", "VT-x", or "VMX" (for "virtual machine extensions"). As we started out rather early on this, we internally use the term "VMX". A thorough explanation of this architecture can be found on [http://www.intel.com/technology/itj/2006/v10i3/1-hardware/5-architecture.htm Intel's pages], but as a summary, with these extensions, a processor always operates in one of the following two modes: 78 78 79 79 * In '''root mode''', its behavior is very similar to the standard mode of operation (without VMX), and this is the context that a virtual machine monitor (VMM) runs in. 80 80 * The '''non-root mode''' (or guest context, if you want) is designed for running a virtual machine. 81 81 82 One notable novelty is that all four privilege levels (rings) are supported in either mode, so guest software can theoretically run at any of them. V MXthen defines transitions from root to non-root mode (and vice versa) and calls these "VM entry" and "VM exit".82 One notable novelty is that all four privilege levels (rings) are supported in either mode, so guest software can theoretically run at any of them. VT-x then defines transitions from root to non-root mode (and vice versa) and calls these "VM entry" and "VM exit". 83 83 84 84 In non-root mode, the processor will automatically cause VM exits for certain privileged instructions and events. For some of these instructions, it is even configurable whether VM exits should occur. 85 85 86 Since, however, nearly all operating systems in use today only make use of ring-0 and ring-3, and since a lot of operations in non-root mode are very expensive, !VirtualBox does not use V MX exactly as intended by Intel. Instead, we make partial use of it -- only where it makes sense and where it helps us to improve performance. So, as said above, our hypervisor, on non-VMX machines, lives in ring 0 of the guest context, below the guest ring-0 code that is actually run in ring 1. When VMXis enabled, the hypervisor can safely live in ring 0 ''host'' context and gets activated automatically by use of the new VM exits.86 Since, however, nearly all operating systems in use today only make use of ring-0 and ring-3, and since a lot of operations in non-root mode are very expensive, !VirtualBox does not use VT-x exactly as intended by Intel. Instead, we make partial use of it -- only where it makes sense and where it helps us to improve performance. So, as said above, our hypervisor, on non-VT-x machines, lives in ring 0 of the guest context, below the guest ring-0 code that is actually run in ring 1. When VT-x is enabled, the hypervisor can safely live in ring 0 ''host'' context and gets activated automatically by use of the new VM exits. 87 87 88 88 So far, we don't support AMD's equivalent to VT-x (called SVM) yet but this is work in process. As you have read above, VT-x support is not of high practical importance and therefore it's not our top priority.
