dev-arm: Verify number of CPUs when restoring Generic Timer Cpts.

When restoring a checkpoint containing a generic timer, the checkpoint
expects to connect the timer to the same number of CPUs that were
present when the checkpoint was taken. If the number of CPUs in the
new simulation is different, deserialization will fail. In the case
that the number of CPUs expected by the checkpoint is greater than the
number of CPUs present, this will cause a segmentation fault caused by
reading off the end of the list of Thread Contexts.

This commit fixes the problem by checking the number of CPUs present
in the simulation matches the number of CPUs expected by the generic
timer checkpoint. If there is a mismatch, a fatal error is triggered
with an informative message to the user.

Change-Id: Iff9ad68d64e67b3df51682b7e4e272e5f355bcd6
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30576
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>

diff --git a/src/dev/arm/generic_timer.cc b/src/dev/arm/generic_timer.cc
index 4f92dac876204af3e38280e93b8b435c0d73a4bf..1b7572838e5b1f4d8d4cec3dac88f6c45c300d76 100644 (file)
--- a/src/dev/arm/generic_timer.cc
+++ b/src/dev/arm/generic_timer.cc
@@ -415,6 +415,13 @@ GenericTimer::unserialize(CheckpointIn &cp)
         cpu_count = OLD_CPU_MAX;
     }
 
+    if (cpu_count != system.threads.size()) {
+        fatal("The simulated system has been initialized with %d CPUs, "
+              "but the Generic Timer checkpoint expects %d CPUs. Consider "
+              "restoring the checkpoint specifying %d CPUs.",
+              system.threads.size(), cpu_count, cpu_count);
+    }
+
     for (int i = 0; i < cpu_count; ++i) {
         CoreTimers &core(getTimers(i));
         core.unserializeSection(cp, csprintf("pe_implementation%d", i));