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.