Re: SMT in Simple?
I had originally considered doing the “hack” of just running multiple CPUs and then restoring on an SMT-enabled detailed CPU (either via checkpoint or modifying the existing switch logic to assign multiple threads from different CPUs to a single CPU).
Doing this would have added specific configuration scripts/logic to re-write checkpoints and require additional gem5 parameters to tell the switch logic how many cores/threads to condense onto a single core.  It seemed like a pretty big hack and the plumbing to do it a bit fragile, so I opted enable SMT on atomic/timing.
By doing it this way, we get to leverage all of the existing gem5 code.  We can dynamically switch back and forth between detailed/atomic/timing (to get to regions of interest / fast-forward).  Getting all of the advantages of cache warming, etc.  


Re: Taking thread-specific code out of SimpleCPU and creating a SimpleCPUThread
Thats kind of what the existing ThreadInfo is doing, the simple CPU will always have to have a way to index to a specific thread context (and iterate over all possible ones).  One thing that could be done to limit the visibility is to have a pointer *curThreadInfo in the atomic/timing base class, that way we’d avoid the lookup based upon “curThread” at the beginning of some functions.  That'd save 2 lines in about 12 places.  But I don’t see a way around for loops iterating across threads in things like snoop logic or drainResume() where we have to check the status of each thread.


Re: ExecContext vs Base
It’s a close-to direct copy of the existing functionality.  All regressions pass with these SMT patches applied (no stat changes whatsoever).  This patch has been pretty thoroughly tested. Linux successfully boots with 4-way SMT atomic/timing and minor (to be posted soon).