| 91 | | 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, this 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). 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. |
| 92 | | 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. 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. |
| | 91 | 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). |
| | 92 | |
| | 93 | 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. |
| | 94 | |
| | 95 | 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. |
| | 96 | |
| | 97 | 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. |
