# Linux Kernel Module Cheat

#### 24.6.2. gem5 checkpoint internals

A quick way to get a gem5 syscall emulation mode or full system checkpoint to observe is:

    ./run --arch aarch64 --emulator gem5 --baremetal userland/freestanding/gem5_checkpoint.S --trace-insts-stdout
    ./run --arch aarch64 --emulator gem5 --userland userland/freestanding/gem5_checkpoint.S --trace-insts-stdout

Checkpoints are stored inside the m5out directory at:

    "$(./getvar --emulator gem5 m5out_dir)/cpt.<checkpoint-time>"

where `<checkpoint-time>` is the cycle number at which the checkpoint was taken.

`fs.py` exposes the `-r N` flag to restore checkpoints, which N-th checkpoint with the largest `<checkpoint-time>`: https://github.com/gem5/gem5/blob/e02ec0c24d56bce4a0d8636a340e15cd223d1930/configs/common/Simulation.py#L118

However, that interface is bad because if you had taken previous checkpoints, you have no idea what `N` to use, unless you memorize which checkpoint was taken at which cycle.

Therefore, just use our superior `--gem5-restore` flag, which uses directory timestamps to determine which checkpoint you created most recently.

The `-r N` integer value is just pure `fs.py` sugar, the backend at `m5.instantiate` just takes the actual tracepoint directory path as input.

The file `m5out/cpt.1000/m5.cpt` contains almost everything in the checkpoint except memory.

It is a Python configparser compatible file with a section structure that matches the SimObject tree e.g.:

    [system.cpu.itb.walker.power_state]
    currState=0
    prvEvalTick=0

When a checkpoint is taken, each `SimObject` calls its overridden `serialize` method to generate the checkpoint, and when loading, `unserialize` is called.