On Sun, Jul 4, 2010 at 4:54 PM, Ali Saidi <sa...@umich.edu> wrote: >> Right, unless it is possible to take a checkpoint with a simple cpu >> and then restore with the inorder cpu. In fact, that brings up my next >> question. How does switching cpu work in conjunction with >> checkpointing? Is it possible to take a checkpoint with a simple cpu >> (old cpu) and then restore from that checkpoint directly into another >> cpu (new cpu)? Or does the restoration from the checkpoint resume into >> the old cpu, switches out the old cpu and then calls the take over >> routine for the new cpu? It looks like that it is the latter case. >> However, if the former can also be done (and is permissible), then I'd >> implement the switchover routine, takeOverFrom(), for inorder and go >> from there. That would reveal if the bug is indeed in the resume part >> of the inorder code or not. > You have to restore into the original CPU, but you only need to be in that > state for 1 cycle (or perhaps even not) before you call switch CPU.
That's the status quo, but that wasn't the original intent. CPU checkpoint state is generic (mostly functional architectural state; I don't know for sure if that's all it is, but I'm pretty sure even if there's more than that it's not CPU model dependent), so there's really no reason that you shouldn't be able to checkpoint one CPU model and restore to a different CPU model. In particular that should be easy for checkpointing an AtomicSimpleCPU and restoring to a more complex model, but because we drain the transient state out of the system before we take a checkpoint, it really ought to work between any pair of CPU models. At some point in the past we were having trouble with that though, and as a workaround we started doing the restore-into-simple-cpu-for-one-cycle thing, and we've never gone back to revisit it. If you think about it, life would be easier if you didn't have to construct this ugly two-headed monster of a config just to restore from a checkpoint. At least that's how I remember it... someone else feel free to speak up if I forgot something. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
