On Mar 17, 2009, at 1:43 AM, Steve Reinhardt wrote:
>
> 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).

I'm pretty sure the patch I was recently working on for SPARC_FS  
bundled unallocated and halted together.

>
> - 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).
There are different states as far as SPARC is concerned. I created a  
initCPU() function that all the ISAs execute at the beginning to do  
the correct thing for initialization. The Alpha CPUs start up  
immediately and start spinning at a known vector, while the SPARC ones  
wait for an explicit start IPI. I think the Unallocated state comes  
from SE mode, where you want to differentiate between a CPU that has  
done exit() and one that has never been used, however maybe that  
doesn't really matter.

Ali


_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to