dev-arm: relax GenericTimer check for CPU count

At Iff9ad68d64e67b3df51682b7e4e272e5f355bcd6 a check was added to prevent
segfaults when unserializing the GenericTimer in case the new number of
thread contexts was smaller than the old one pre-checkpoint.

However, GenericTimer objects are only created dynamically as needed after
timer miscreg accesses. Therefore, if we take the checkpoint before
touching those registers, e.g. from a simple baremetal example, then the
checkpoint saves zero timers, and upon restore the assert would fail
because we have one thread context and not zero:

> fatal: The simulated system has been initialized with 1 CPUs, but the
Generic Timer checkpoint expects 0 CPUs. Consider restoring the checkpoint
specifying 0 CPUs.

This commit solves that by ensuring only that the new thread context count
larger than, but not necessarily equal to the number of cores.

Change-Id: I8bcb05a6faecd4b4845f7fd4d71df95041bf6c99
JIRA: https://gem5.atlassian.net/browse/GEM5-703
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31894
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>

src/dev/arm/generic_timer.cc

@@ -426,7 +426,11 @@ GenericTimer::unserialize(CheckpointIn &cp)
         cpu_count = OLD_CPU_MAX;
     }
 
-    if (cpu_count != system.threads.size()) {
+    // We cannot assert for equality here because CPU timers are dynamically
+    // created on the first miscreg access. Therefore, if we take the checkpoint
+    // before any timer registers have been accessed, the number of counters
+    // is actually smaller than the total number of CPUs.
+    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.",