On 11.01.2013 17:41, Steve Reinhardt wrote:
> On Fri, Jan 11, 2013 at 2:17 PM, Nilay Vaish <[email protected]> wrote: > >> On Fri, 11 Jan 2013, Steve Reinhardt wrote: >> >>> I believe the HandyM5Reg value is already serialized as part of the misc reg file. I think you could solve the problem with fewer changes just by calling decoder->setM5Reg after unserializing the register file. >> The misc reg file is part of the isa section of the checkpoint and the isa is now a separate sim object. The decoder can only be accessed via the simple thread structure. This means that the isa should be unserialized before the thread state. I think we do want to rely on the ordering. And there is no initialization function that is called after loadState() has been called on the sim objects. > > If the ISA object knew which CPU it belonged to, it could call > cpu->decoder->setM5Reg() in its loadState() method after unserialize(). It > looks like it doesn't know, but we could change that. (Actually I missed > this recent change... I'm a little unomfortable with it, since it seems to > jumble together both ISA traits and ISA-specific state. Looks like we're > already running into an unforeseen downside too. And I don't really like > the name, something like ISASpecificState would be better if that's really > what we want it to be. Anyway, the bottom line here is that that change is > recent enough that I don't think we should take that aspect of the code as > an inviolable constraint in solving this other problem.) > > In fact I see now that X86ISA::ISA::unserialize() already calls > updateHandyM5Reg(), which calls tc->getDecodePtr()->setM5Reg() when the tc > argument is non-NULL. So arguably the problem here is only that this > particular call to updateHandyM5Reg() passes in NULL for the tc, since it > doesn't know any better. If the ISA object knew which CPU it belonged to, > it could set its tc value in init(). > > Another option is to use the startup() method on the CPU do to this, since > that is called after loadState() is called on all objects. That's a little > less elegant, IMO, but is perhaps less invasive to the status quo. > > Steve > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev [1] The reason for the ISA object was to have a location where CPU specific features could be configured. Previously some of this was done in the XXXXXSystem Object, however that has a couple of issues associated with it. The biggest one is that there is only one system object and possibly multiple CPUs. If you need to give CPUs traits like CPU IDs that have a specific NUMA-like meaning or want to configure CPUs to report themselves to the kernel in different ways (e.g. big.LITTLE so the kernel can make intelligent scheduling decisions), there isn't a way to do this in that framework. The other reason is that it's quite ugly to go spelunking in the TC, to get a system pointer and then dynamically cast it to a architecture specific system pointer to get at what a the value of a miscellaneous register should be. Thanks, Ali Links: ------ [1] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
