Changes between Version 26 and Version 27 of VirtualBox architecture

Timestamp:

Jan 11, 2007 6:31:02 PM (18 years ago)

Author:

jose

Comment:

--

VirtualBox architecture

@@ -87 +87 @@
 We also have experimental support for AMD's equivalent to VT-x (called AMD-V or SVM). As you have read above, VT-x support is not of high practical importance and we have noticed that AMD's implementation comes with an even larger performance penalty plus a number of implementation errors, improving our support for ADM-V is currently not the most important item.
 
-== Advanced Techniques ==
+== Advanced techniques: code scanning, analysis and patching ==
 
-As mentioned before, we try to execute all guest code directly and only fallback to the recompiler in very rare situations. However, when executing guest ring 0 code in ring 1, a lot of additional instruction faults occur. This is because ring 1 is not allowed to execute privileged instructions. Every time we fault, the VMM steps in and emulates the desired behavior. This works perfectly well but the resulting performance will be very poor because CPU faults tend to be very expensive and there will be thousands of them per second. For raw ring 3, it is not a major problem as the number of faults generally does not increase by a large factor (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).
+As described above, we normally try to execute all guest code natively and use the recompiler as a fallback only in very rare situations. For raw ring 3, the performance penalty caused by the recompiler is not a major problem as the number of faults is generally 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).
 
-In addition to excessive faults, there are also occasional compatibility problems because some system instructions do not fault when called in ring 1 but just behave differently (one of the design flaws of IA32/AMD64 that were never addressed). Such instructions have to be found and replaced.
+However, as was also described previously, we manipulate the guest operating system to actually execute its ring-0 code in ring 1. This causes a lot of additional instruction faults, as ring 1 is not allowed to execute any privileged instructions (of which there are plenty in the guest's ring-0 code, of course). With each of these faults, our VMM must step in and emulate the code to achieve the desired behavior. While this normally works perfectly well, the resulting performance would be very poor since CPU faults tend to be very expensive and there will be thousands and thousands of them per second. 
 
-To address these two issues, we have come up with a set of unique technologies that we have called "Patch Manager" (PATM) and "Code Scanning and Analysis Manager" (CSAM). Before executing ring 0 code, we scan it recursively to discover problematic instructions. We then perform in-situ patching, i.e. we replace the instruction by 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 can be many odd situations we have to discover and handle correctly. With its current complexity, one could also argue that Patch Manager is an advanced in-situ recompiler.
+To make things worse, running ring-0 code in ring 1 causes some nasty occasional compatibility problems. Because of design flaws in the IA32/AMD64 architecture that were never addressed, some system instructions that ''should'' cause faults when called in ring 1 unfortunately do not. Instead, they just behave differently. It is therefore imperative that these instructions be found and replaced.
 
-Also, when taking a fault, we look at the fault reason to see if we can eliminate this fault in the future by installing a patch. This turns out to work so well that the number of additional faults we get due to the virtualization is very small and the resulting performance is far better than a typical recompiler or VT-x.
+To address these two issues, we have come up with a set of unique techniques that we call "Patch Manager" (PATM) and "Code Scanning and Analysis Manager" (CSAM). Before executing ring 0 code, we scan it recursively to discover problematic instructions. We then perform ''in-situ'' patching, i.e. we replace 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, we analyze the fault's cause to determine if it is possible to patch the offending code to prevent it from causing more expensive faults in the future. This turns out to work very well, and we can reduce the faults caused by our virtualization to a rate that performs much better than a typical recompiler, or even VT-x technology, for that matter.