From 27e65633f117b655528bf56fb092b130dcdfcdbc Mon Sep 17 00:00:00 2001 From: Richard Cooper Date: Wed, 17 Jun 2020 15:30:51 +0100 Subject: [PATCH] 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 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30576 Tested-by: kokoro Maintainer: Giacomo Travaglini --- src/dev/arm/generic_timer.cc | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/dev/arm/generic_timer.cc b/src/dev/arm/generic_timer.cc index 4f92dac87..1b7572838 100644 --- 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)); -- 2.30.2