Virtualization requires that you have a complete copy of the entire OS running, and all code execution is opaque to the host. That means all execution of code i

Virtualization requires that you have a complete copy of the entire OS running, and all code execution is opaque to the host. That means all execution of code is just in time - because it's not native - and you can't have any part of virtualization running optimized arm code - because you're in a virtualized x86 box. Translation on the other hand involves basically parsing the object files, finding entry points, translating those, and then occasionally jit compiling when the code was doing something funky so your entry points were wrong (think obfuscation, compilers written the night before a compiler assignment was due :D ). And of course JITs themselves. JITs (especially self modifying ones) are a particular pain point for all engines be they virtualization or translation, because they necessarily require you to recompile or invalidate pretty much entire pages of compiled code. Unfortunately virtualizing a machine with a different instruction set gives you an opaque view of what is happening so takes all executed code far closer to the JIT/interpret only end of the spectrum. So the end result of this is you get a much because resource impact - you've loaded a full clone of the OS on a virtualised machine, so you may not even be able to leverage hardware virtualization support (I imagine with some skullduggery it could be possible), and even if you could you now have duplicate page tables as well. Then you have the perf impact which is because the outside environment is opaque to the VM you lose a lot of your ability to rely on code not changing, or to perform any AOT work. Now some of these may be mitigable, but at some point you have to ask why you would bother when translation has lower resource usage, higher performance, and can be made much more seamless.