KVM is Linux kernel interface that greatly speeds up execution of virtual machines.
You can make QEMU or gem5 by passing enabling KVM with:
+You can make QEMU or gem5 by passing enabling KVM with:
but it was broken in gem5 with pending patches: https://www.mail-archive.com/gem5-users@gem5.org/msg15046.html It fails immediately on:
-panic: KVM: Failed to enter virtualized mode (hw reason: 0x80000021)-
KVM works by running userland instructions natively directly on the real hardware instead of running a software simulation of those instructions.
TODO: do the right thing and cross compile QEMU and gem5. gem5’s Python parts might be a pain. QEMU should be easy: https://stackoverflow.com/questions/26514252/cross-compile-qemu-for-arm
While gem5 does have KVM, as of 2019 its support has not been very good, because debugging it is harder and people haven’t focused intensively on it.
+X86 was broken with pending patches: https://www.mail-archive.com/gem5-users@gem5.org/msg15046.html It failed immediately on:
+panic: KVM: Failed to enter virtualized mode (hw reason: 0x80000021)+
Bibliography:
+The only hairy thing in QEMU is the binary code generation.
gem5 however has tended towards intensive code generation in order to support all its different hardware types:
-lots of magic happen on top of pybind11, which is already magic, to more automatically glue the C++ and Python worlds: gem5 Python C++ interaction
-.isa code which describes most of the instructions
-Ruby for memory systems
-gem5 however has tended towards horrendous intensive code generation in order to support all its different hardware types
KVM CPUs are an alternative way of fast forwarding boot when they work.
+gem5 uses a ton of code generation, which makes the project horrendous:
+lots of magic happen on top of pybind11, which is already magic, to more automatically glue the C++ and Python worlds: gem5 Python C++ interaction
+.isa code which describes most of the instructions
+Ruby for memory systems
+To find the definition of generated code, do a:
+grep -I -r build/ 'code of interest'+
where:
+-I: ignore binray file matches on built objects
-r: ignore symlinks due to Why are all C++ symlinked into the gem5 build dir? as explained at https://stackoverflow.com/questions/21738574/how-do-you-exclude-symlinks-in-a-grep
The code generation exists partly to support insanely generic cross ISA instructions mapping to one compute model, where it might be reasonable.
+But it has been widely overused to insanity. It likely also exists partly because when the project started in 2003 C++ compilers weren’t that good, so you couldn’t rely on features like templates that much.
+Generated code at: build/<ISA>/config/the_isa.hh which contains amongst other lines:
#define X86_ISA 8
+
+enum class Arch {
+ X86ISA = X86_ISA
+};
+
+#define THE_ISA X86_ISA
+Generation code: src/SConscript at def makeTheISA.
Tested on gem5 211869ea950f3cc3116655f06b1d46d3fa39fb3a.
+Bibliography: https://www.mail-archive.com/gem5-users@gem5.org/msg16989.html
+E.g. src/cpu/decode_cache.hh includes:
Some scons madness.
It was not possible to disable the symlinks automatically for the entire project when I last asked: https://stackoverflow.com/questions/53656787/how-to-set-disable-duplicate-0-for-all-scons-build-variants-without-repeating-th
The horrendous downsides of this are:
+when debugging the emulator, it shows you directories inside the build directory rather than in the source tree
+it is harder to separate which files are generated and which are in-tree when grepping for code generated definitions
+