Changes between Version 4 and Version 5 of VirtualBox architecture

Timestamp:

Nov 16, 2006 4:49:15 PM (17 years ago)

Author:

jose

Comment:

--

VirtualBox architecture

@@ -13 +13 @@
  1. `VirtualBox`, the GUI for the main window;
  1. another `VirtualBox` process that was started with the `-startvm` parameter, which means that its GUI process acts as a shell for a VM;
- 1. `VirtualBoxSVC`, a daemon running in the background that keeps track of all the processes involved (this was automatically started by the first GUI process).
+ 1. `VBoxSVC`, a service running in the background that keeps track of all the processes involved (this was automatically started by the first GUI process).
 
 (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.)
 
-The VM that runs "inside" the second window looks like just another Qt process to the host operating system. !VirtualBox is very well behaved in that respect: it pretty much takes over control over a large part of your computer, executing a complete operating system with its own set of guest processes, drivers, and devices inside this VM process, but the host operating system does not notice much of this. Whatever the VM does, it's just another process in your host operating system.
+The VM that runs "inside" the second window looks like just another Qt process to the host operating system (OS). !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.
 
 We therefore have two sorts of encapsulation in place with the various !VirtualBox files and processes:
@@ -23 +23 @@
  1. '''Client/server architecture.''' All aspects of !VirtualBox and the VMs that are running can be controlled with a simple, yet powerful, COM/XPCOM API. For example, there is a command-line utility called `VBoxManage` that allows you to control VMs just like the GUI does (in fact, many of the more sophisticated operations are not yet supported by the GUI). You can, for example, start a VM from the GUI (by clicking on the "Start" button) and stop it again from `VBoxManage`. 
 
- This is why the server process (`VBoxSVC`) is needed: it acts as a librarian of what VMs are running and what states their in. 
+ This is why the service process (`VBoxSVC`) is needed: it acts as a librarian of what VMs are running and what states their in. 
 
- 2. '''Frontend/backend architecture.''' The guts of !VirtualBox -- everything that makes x86 virtualization complicated and messy -- are hidden in a shared library, `VBoxVMM.dll`, or `VBoxVMM.so` on Linux. This can be considered a "backend" that is static, and it is easy to write another frontend without having to mess with the gory details of x86 virtualization. So, as an example, if you don't like the fact that the GUI is a Qt application, you can easily write a different frontent (say, using GTK). 
+ 2. '''Frontend/backend architecture.''' The guts of !VirtualBox -- everything that makes x86 virtualization complicated and messy -- are hidden in a shared library, `VBoxVMM.dll`, or `VBoxVMM.so` on Linux. This can be considered a "backend", or black box, that is static, and it is relatively easy to write another frontend without having to mess with the gory details of x86 virtualization. So, as an example, if you don't like the fact that the GUI is a Qt application, you can easily write a different frontend (say, using GTK). 
 
  In fact, !VirtualBox already comes with several frontends:
 
-   * The Qt GUI (`VirtualBox`) that you may already be familiar with.
+ * The Qt GUI (`VirtualBox`) that you may already be familiar with.
 
-   * `VBoxManage`, a command-line utility that allows you to control all of !VirtualBox's powerful features.
+ * `VBoxManage`, a command-line utility that allows you to control all of !VirtualBox's powerful features.
 
-   * 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`.
+ * 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`.
 
-   * An RDP server, which does not produce visible output on the host, but allows remote computers to connect to it. 
-     
-     (The RDP server is not part of !VirtualBox Open Source Edition, but is available with the full version; see the [Editions] page for details.
+ * An RDP server, which is console-only and produces no graphical output on the host, but allows remote computers to connect to it via the Remote Desktop Protocol (RDP). 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.)
+
+== Inside a virtual machine ==
+
+As said above, from the perspective of the host OS, a virtual machine is just another process. The host OS does not need much tweaking to support virtualization.
+
+When a VM is running, from your processor's point of view, your computer can be in one of several states:
+
+ 1. It can be '''executing host ring-3 code''' (e.g. from other host processes), or '''host ring-0 code,''' just as it would be if !VirtualBox wasn't running.
+ 2. It can be '''emulating guest code'''. Basically, !VirtualBox tries to run as much guest code natively as possible and emulates guest code when it is lost about why guest code is not working. Typically, the emulator steps in as a fallback when 
+    * guest code disables interrupts and !VirtualBox cannot determine when they will be switched back on;
+    * for execution of certain single instructions; this typically happens when a nasty guest instruction such as `LIDT` has caused a trap and needs to be emulated;
+    * for any real-mode code (e.g. BIOS code, a DOS guest, or any operating system startup).
+ 3. It can be '''running guest ring-3 code natively.''' In !VirtualBox, this is called "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.
+ 4. It 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). 
+
+Also, in the !VirtualBox source code, you will find lots of references to "host context" or "guest context". Essentially, these mean:
+
+ * '''Host context (HC)''' means that the host OS is in control of everything including virtual memory. Here, as normally, you have ring 3 and ring 0.
+
+ * '''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 
+   * ring 3 (hopefully executed in "raw mode" all the time);
+   * ring 1 (of which the guest thinks it's ring 0, see above), and 
+   * ring 0 (which is !VirtualBox code). This guest-context ring-0 code is also often called a "hypervisor". 
+
+Finally, there is also a ring-0 driver that must be loaded in the host OS for !VirtualBox to work. However, this ring-0 driver does less than you may think. It is only needed for a few specific tasks, such as:
+
+ * allocating physical memory for the VM;
+
+ * saving and restoring CPU registers and descriptor tables when a host interrupt occurs while a guest's ring-3 code is executing (e.g. when the host OS wants to reschedule); 
+
+ * when switching from host ring-3 to guest context;
+
+ * enable or disable Vanderpool etc. support.
+
+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 hundereds of processes, is only scheduled when the host OS gives the VM process a timeslice. 
 
 
 
-== 
-
-
-