Steve Reinhardt wrote:
> I'm running into yet more problems with the varying interpretations of
> thread status, so I'd like to get this cleared up. For reference,
> here's the current enum in thread_context.hh:
>
> enum Status
> {
> /// Initialized but not running yet. All CPUs start in
> /// this state, but most transition to Active on cycle 1.
> /// In MP or SMT systems, non-primary contexts will stay
> /// in this state until a thread is assigned to them.
> Unallocated,
>
> /// Running. Instructions should be executed only when
> /// the context is in this state.
> Active,
>
> /// Temporarily inactive. Entered while waiting for
> /// synchronization, etc.
> Suspended,
>
> /// Permanently shut down. Entered when target executes
> /// m5exit pseudo-instruction. When all contexts enter
> /// this state, the simulation will terminate.
> Halted
> };
>
> Those definitions seem reasonable, but the usage is very inconsistent.
> Here are just a few things that appear to be happening:
>
> - Though the SimpleCPU models follow the comments and initialize
> threads in Unallocated, the O3 and InOrder CPUs initialize threads to
> Suspended. I haven't tried this recently, but I recall that simply
> changing the initialization code in O3 to start in Unallocated causes
> other things to break.
>
> - Even though the comment says that a thread in the Halted state is
> "permanently" halted, the MIPS MT implementation appears to use this
> state for something that looks more like a software-controlled
> suspend.
>
> - The Halted state is entered via some Alpha PAL instruction (maybe
> cause by m5exit as the comment indicates), but an exit() call in SE
> mode causes a thread to move back to Unallocated rather than Halted.
>
> - The SPARC readFSReg function in ua2005.c looks like it is supposed
> to return thread status information to the guest, and only has cases
> for Active, Suspended, and Halted (and will panic if it ever queries a
> thread that's Unallocated).
>
> - Other than the SPARC function mentioned above, I don't see anything
> that ever looks to see if a thread is in the Halted state (i.e., it's
> almost write-only).
>
> It seems to me that we ought to be able to get away with just three states:
>
> 1. Active: no confusion there
> 2. Temporarily inactive (think "paused")... what is basically
> Suspended now, though I'm still confused about why InOrderCPU and O3
> initialize threads to this state.
> 3. Stopped, basically combining both Halted and Unallocated.
>
> The basic difference between #2 and #3 is that in #2 the thread
> context has a software thread assigned to it but is just waiting to
> resume execution, where in #3 there is no software thread assigned to
> the context. I'm inclined to keep the Suspended and Halted names,
> though this would be a good time to pick new ones if anyone felt that
> would be helpful. (Particularly given that I expect the "halt"
> instruction in x86 if not in other ISAs to actually move a thread to
> Suspended rather than Halted, we may want to pick a different name for
> state #3.)
>
> I expect there's no way to really know whether a particular scheme
> will work except to try it, but any comments or insight anyone could
> provide up front would be helpful. I'm particularly curious about (1)
> what if any semantics SPARC attributes to these various states based
> on their exposure to software in the misc reg mentioned above and (2)
> why it would matter that a CPU is initialized to Suspended rather than
> Halted or Unallocated (since I know Gabe, Polina, and Ali have all
> wrestled with this in FS mode recently).
>
> Thanks,
>
> Steve
> _______________________________________________
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>
I think Ali was the one that implemented the SPARC register you ask
about in 1. The x86 halt instruction does put you into a suspended state
where you'll wake back up if you get an interrupt. Another item for your
list could be that some CPU models are unwilling to start a thread as
suspended. Your three state system seems like a better idea than the old
four state one.
Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
