On Fri, Apr 17, 2009 at 9:42 AM, Gabe Black <gbl...@eecs.umich.edu> wrote:
> > So the idea is that we only call initCPU() if the thread is in the > > Suspended state (I believe there's a more straightforward way to code > > that!), which the comment implies is because we only want to call > > initCPU() when the thread is just starting up. There's no indication > > of why we would ever call FullO3CPU<Impl>::init() when the thread > > isn't just starting up though (i.e., did this check ever fail in > > practice?). Does it have something to do with creating an O3CPU but > > not starting it up right away because we're starting in SimpleCPU > > instead and are going to do a switchover later? This condition isn't > > present in any of the SimpleCPU models. > > I'm not an expert on this code, but I think it's preventing excessively > restarting the CPU if you do a switchover or resume from a checkpoint. Yea, that's exactly my assumption too, but I'd feel much better if someone could explain in detail why it's necessary rather than just leaving it in out of the fear of the unknown. For example, it seems wrong that init() would get called more than once on the same object. Also if there are cases where init() is called and the thread is *not* in its initial state, then when & where did the thread's state get changed? > > As far as wakeup, I think there should be at least a warning and maybe > > an assertion if you wakeup a Halted cpu. My thought is that a Halted > > CPU doesn't have a PC to run from, so it doesn't make sense just to > > wake it up. If there is a PC for it to run from it should be in > > Suspended. If it's assigned a PC but you don't want it to start > > running right away, it should transition from Halted to Suspended at > > that time. This model may not work cleanly with starting up a CPU via > > an interrupt, and I'm willing to rethink it if that's the case, but > > let's do it deliberately and not ad hoc. > > > > > So halted would be basically powered off and uninitialized and suspended > would be ready and waiting for something to do? Pretty much... Halted is uninitialized from a SW perspective, anyway, while Suspended is not just waiting for something to do, but knowing what it supposed to be doing and just waiting for the signal to go do it (e.g., waiting on a lock or an interrupt). > In that case, I'd want > to initialize the unused CPUs to suspended and make the "halt" microop > use suspended because the CPUs couldn't be started otherwise. If I'm > just using it wrong I'll stop doing that :) Yes, one of the little ironies is that this means that the x86 HLT instruction should put the thread in the Suspended state and not the Halted state. The unused CPUs in x86 FS mode do start out in Suspended, since that's what the x86-specific startupCPU() function does with them (at the same time it activates the boot CPU). This seems exactly right to me: ThreadContexts start out as Halted by default, then can be put in Active or Suspended as appropriate when they are configured to run software, either by the Process code (for SE mode) or by the ISA-specific code (for FS mode), since the details of MP boot are ISA/platform specific. Steve
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
