# Linux Kernel Module Cheat

#### 24.6.3. gem5 checkpoint restore and run a different script

You want to automate running several tests from a single pristine post-boot state.

The problem is that boot takes forever, and after the checkpoint, the memory and disk states are fixed, so you can’t for example:

- hack up an existing rc script, since the disk is fixed

- inject new kernel boot command line options, since those have already been put into memory by the bootloader

There is however a few loopholes, m5 readfile being the simplest, as it reads whatever is present on the host.

So we can do it like:

    # Boot, checkpoint and exit.
    printf 'echo "setup run";m5 exit' > "$(./getvar gem5_readfile_file)"
    ./run --emulator gem5 --eval 'm5 checkpoint;m5 readfile > /tmp/gem5.sh && sh /tmp/gem5.sh'

    # Restore and run the first benchmark.
    printf 'echo "first benchmark";m5 exit' > "$(./getvar gem5_readfile_file)"
    ./run --emulator gem5 --gem5-restore 1

    # Restore and run the second benchmark.
    printf 'echo "second benchmark";m5 exit' > "$(./getvar gem5_readfile_file)"
    ./run --emulator gem5 --gem5-restore 1

    # If something weird happened, create an interactive shell to examine the system.
    printf 'sh' > "$(./getvar gem5_readfile_file)"
    ./run --emulator gem5 --gem5-restore 1

Since this is such a common setup, we provide the following helpers for this operation:

- `./run --gem5-readfile` is a convenient way to set the `m5 readfile` file contents from a string in the command line, e.g.:

      # Boot, checkpoint and exit.
      ./run --emulator gem5 --eval './gem5.sh' --gem5-readfile 'echo "setup run"'

      # Restore and run the first benchmark.
      ./run --emulator gem5 --gem5-restore 1 --gem5-readfile 'echo "first benchmark"'

      # Restore and run the second benchmark.
      ./run --emulator gem5 --gem5-restore 1 --gem5-readfile 'echo "second benchmark"'

- rootfs_overlay/lkmc/gem5.sh. This script is analogous to gem5’s in-tree hack_back_ckpt.rcS, but with less noise.

  Usage:

      # Boot, checkpoint and exit.
      ./run --emulator gem5 --eval './gem5.sh' --gem5-readfile 'echo "setup run"'

      # Restore and run the first benchmark.
      ./run --emulator gem5 --gem5-restore 1 --gem5-readfile 'echo "first benchmark"'

      # Restore and run the second benchmark.
      ./run --emulator gem5 --gem5-restore 1 --gem5-readfile 'echo "second benchmark"'

Their usage is also exemplified at gem5 run benchmark.

If you forgot to use an appropriate `--eval` for your boot and the simulation is already running, rootfs_overlay/lkmc/gem5.sh can be used directly from an interactive guest shell.

First we reset the readfile to something that runs quickly:

    printf 'echo "first benchmark"' > "$(./getvar gem5_readfile_file)"

and then in the guest, take a checkpoint and exit with:

    ./gem5.sh

Now the guest is in a state where readfile will be executed automatically without interactive intervention:

    ./run --emulator gem5 --gem5-restore 1 --gem5-readfile 'echo "first benchmark"'
    ./run --emulator gem5 --gem5-restore 1 --gem5-readfile 'echo "second benchmark"'

Other loophole possibilities to execute different benchmarks non-interactively include:

- 9P

- Secondary disk

- `expect` as mentioned at: https://stackoverflow.com/questions/7013137/automating-telnet-session-using-bash-scripts

      #!/usr/bin/expect
      spawn telnet localhost 3456
      expect "# $"
      send "pwd\r"
      send "ls /\r"
      send "m5 exit\r"
      expect eof

  This is ugly however as it is not deterministic.

https://www.mail-archive.com/gem5-users@gem5.org/msg15233.html