From fcc3fd3db06d17a39e81be5baed7f367b9b93ef8 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: Thu, 12 Mar 2020 00:00:02 +0000 Subject: [PATCH] Linux kernel early boot messages and gem5 m5out/system.dmesg file --- README.adoc | 45 +++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 43 insertions(+), 2 deletions(-) diff --git a/README.adoc b/README.adoc index d69eb66..1796e54 100644 --- a/README.adoc +++ b/README.adoc @@ -2028,6 +2028,31 @@ I also tried to hack `run-gdb` with: and no I do have the symbols from `arch/arm/boot/compressed/vmlinux'`, but the breaks still don't work. +==== Linux kernel early boot messages + +When booting Linux on a slow emulator like <>, what you observe is that: + +* first nothing shows for a while +* then at once, a bunch of message lines show at once followed on aarch64 Linux 5.4.3 by: ++ +.... +[ 0.081311] printk: console [ttyAMA0] enabled +.... + +This means of course that all the previous messages had been generated earlier and stored, but were only printed to the terminal once the terminal itself was enabled. + +Notably for example the very first message: + +.... +[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd070] +.... + +happens very early in the boot process. + +If you get a failure before that, it will be hard to see the print messages. + +One possible solution is to parse the dmesg buffer, gem5 actually implements that: <>. + === GDB step debug userland processes QEMU's `-gdb` GDB breakpoints are set on virtual addresses, so you can in theory debug userland processes as well. @@ -10588,6 +10613,11 @@ Using text mode is another workaround if you don't need GUI features. Getting started at: xref:gem5-buildroot-setup[xrefstyle=full]. +gem5 has a bunch of crappiness, mostly described at: <>, but it does deserve some credit on the following points: + +* insanely configurable system topology from Python without recompiling, made possible in part due to a well defined memory packet structure that allows adding caches and buses transparently +* each micro architectural model (<>) works with all ISAs + === gem5 vs QEMU * advantages of gem5: @@ -12020,6 +12050,17 @@ Contains UART output, both from the Linux kernel or from the baremetal system. Can also be seen live on <>. +[[gem5-m5out-system-dmesg-file]] +==== gem5 m5out/system.dmesg file + +TODO confirm and create minimal example. + +I think this file is capable of showing terminal messages before they reach the terminal by parsing the dmesg buffer from memory. + +This could be used to debug the Linux kernel boot if problems happen before the serial is enabled: <>. + +The file appears to get dumped only on kernel panic which gem5 can detect by the PC address: <>. + [[gem5-m5out-stats-txt-file]] ==== gem5 m5out/stats.txt file @@ -20926,7 +20967,7 @@ Run all kernel boot benchmarks for one arch: cat "$(./getvar test_boot_benchmark_file)" .... -Sample results at 8fb9db39316d43a6dbd571e04dd46ae73915027f: +Sample results at LKMC 8fb9db39316d43a6dbd571e04dd46ae73915027f: .... cmd ./run --arch x86_64 --eval './linux/poweroff.out' @@ -21443,7 +21484,7 @@ Ubuntu 19.10, GCC 9.2.1, LKMC 7c6bb29bc89ec3f1056c0680c3f08bd64018a7bc, gem5 d7d Same but gem5 d7d9bc240615625141cd6feddbadd392457e49eb (2018-06-17) hacked with `-Wnoerror`: 11m 37s. So there was a huge regression in the last two years! We have to find it out. -A profiling of the build has been done at: https://gem5.atlassian.net/browse/GEM5-277 +A profiling of the build has been done at: https://gem5.atlassian.net/browse/GEM5-277 Analysis there showed that d7d9bc240615625141cd6feddbadd392457e49eb (2018-06-17) is also composed of 50% pybind11 and with no obvious time sinks. ====== pybind11 accounts for 50% of gem5 build time