sim,cpu: Move the call to initCPU into System.
authorGabe Black <gabeblack@google.com>
Wed, 29 Jan 2020 11:22:05 +0000 (03:22 -0800)
committerGabe Black <gabeblack@google.com>
Sat, 1 Feb 2020 12:31:14 +0000 (12:31 +0000)
commitdc328d00ebe798f0b0ee8903aca4256bb128dc6f
treed7e3681f46796bf55b61ec92916ce6f2057295e6
parent5d3f1bfc48346f671c2b72ad06b3822c64457438
sim,cpu: Move the call to initCPU into System.

The call to initCPU was moved into initState in the base CPU class
since it should only really be called when starting a simulation
fresh. Otherwise checkpointed state will be loaded over the state of
the CPU anyway, so there's no reason to set up anything else.

Unfortunately that made it possible for the System level initialization
and the CPU initialization to happen out of order, effectively letting
initCPU clobber the state the System might have set up to prepare for
executing a kernel for instance.

To work around that issue, the call was moved to init which would
necessarily happen before initState, restoring the original ordering.

This change moves the change *back* into initState, but of the System
class instead of the CPU class. This makes it possible to guarantee
that OS initialization happens after initCPU since that's also done
by System subclasses, and they control when they call initCPU of the
base class.

This also slightly simmplifies when initCPU is called since we
shouldn't need to check whether a context is switched out or not. If
it's registered with the System object, then it should be in a
currently swapped in CPU.

This also puts the initCPU and startupCPU calls right next to each
other. A future change will take advantage of that and merge the
calls together.

Also, because there are already ISA specific subclasses of System
which already have specialized versions of initState, we should be
able to move the code in initCPU and startupCPU directly into those
subclasses. That will give those subclasses more flexibilty if, for
instance, they want all CPUs to start running in the BIOS like they
would on a real system, or if they want only the BSP to be active
as if the BIOS had already paused the APs before passing control to
a bootloader or OS.

This will also remove another two TheISA:: style functions, reducing
the number of global dependencies on a single ISA.

Change-Id: Ic56924660a5b575a07844a198f69a0e7fa212b52
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24903
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
src/arch/null/utility.hh
src/cpu/base.cc
src/sim/system.cc