From 985913e1e6d8fb3b5772fe500408028253ad9cd6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ciro=20Santilli=20=E5=85=AD=E5=9B=9B=E4=BA=8B=E4=BB=B6=20?= =?UTF-8?q?=E6=B3=95=E8=BD=AE=E5=8A=9F?= Date: Sun, 18 Nov 2018 00:00:00 +0000 Subject: [PATCH] prepare for kvm testing --- README.adoc | 24 ++++++++++++------------ build | 2 ++ 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/README.adoc b/README.adoc index 5b9c739..5413531 100644 --- a/README.adoc +++ b/README.adoc @@ -505,14 +505,14 @@ The limitations are severe however: * can't <>, since the source and cross toolchain with GDB are not available. Buildroot cannot easily use a host toolchain: <>. + Maybe we could work around this by just downloading the kernel source somehow, and using a host prebuilt GDB, but we felt that it would be too messy and unreliable. -* you won't get the latest version of this repository. Our <> attempt to automate builds failed, and storing a release for every commit would likely make GitHub mad at us. +* you won't get the latest version of this repository. Our <> attempt to automate builds failed, and storing a release for every commit would likely make GitHub mad at us anyways. * <> is not currently supported, although it should not be too hard to do. Annoyances: + ** there is no Debian package for it, so you have to compile your own, so you might as well just build the image itself ** it does not handle <>, and we haven't gotten <> to work yet, therefore we would have to either distribute large ext2 images, or constantly fight with <> ** QEMU uses `bzImage` and gem5 the raw `vmlinux`, and we don't want to distribute the same thing twice... + -And our attempt at using link:https://github.com/torvalds/linux/blob/master/scripts/extract-vmlinux[`extract-vmlinux`] failed for `aarch64` with: +Our attempt at using link:https://github.com/torvalds/linux/blob/master/scripts/extract-vmlinux[`extract-vmlinux`] to convert between them failed for `aarch64` with: + .... run-detectors: unable to find an interpreter for @@ -2824,7 +2824,9 @@ gem5 can generate DTBs on ARM with `--generate-dtb`, but we don't use that featu == KVM -You can make QEMU or gem5 <> by passing enabling KVM with: +link:https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine[KVM] is Linux kernel interface that <> execution of virtual machines. + +You can make QEMU or gem5 by passing enabling KVM with: .... ./run --kvm @@ -2836,21 +2838,19 @@ but it was broken in gem5 with pending patches: https://www.mail-archive.com/gem panic: KVM: Failed to enter virtualized mode (hw reason: 0x80000021) .... -KVM uses the link:https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine[KVM Linux kernel feature] of the host to run most instructions natively. +KVM works by running userland instructions natively directly on the real hardware instead of running a software simulation of those instructions. + +Therefore, KVM only works if you the host architecture is the same as the guest architecture. This means that this will likely only work for x86 guests since almost all development machines are x86 nowadays. Unless you are link:https://www.youtube.com/watch?v=8ItXpmLsINs[running an ARM desktop for some weird reason] :-) We don't enable KVM by default because: -* only works if the architecture of the guest equals that of the host. -+ -We have only tested / supported it on x86, but it is rumoured that QEMU and gem5 also have ARM KVM support if you are link:https://www.youtube.com/watch?v=8ItXpmLsINs[running an ARM desktop for some weird reason] :-) -* limits visibility, since more things are running natively: +* it limits visibility, since more things are running natively: ** can't use GDB ** can't do instruction tracing -* kernel boots are already fast enough without `-enable-kvm` +** on gem5, you lose cycle counts and therefor any notion of performance +* QEMU kernel boots are already fast enough for most purposes without it -The main use case for `-enable-kvm` in this repository is to test if something that takes a long time to run is functionally correct. - -For example, when porting a benchmark to Buildroot, you can first use QEMU's KVM to test that benchmarks is producing the correct results, before analysing them more deeply in gem5, which runs much slower. +One important use case for KVM is to fast forward gem5 execution, often to skip boot, take a <>, and then move on to a more detailed and slow simulation == User mode simulation diff --git a/build b/build index c24c4e9..14c4eb4 100755 --- a/build +++ b/build @@ -129,10 +129,12 @@ name_to_component_map = { 'device-tree-compiler', 'diod', 'libgoogle-perftools-dev', + 'm4', 'protobuf-compiler', 'python-dev', 'python-pip', 'scons', + 'zlib1g-dev', }, python2_pkgs={ # Generate graphs of config.ini under m5out.