Ok, thanks. I'll put together a CL removing the checkpointing. It should be backwards compatible with old checkpoints still since new versions of gem5 will just ignore the extra state in the checkpoint.
Gabe On Tue, Jan 14, 2020 at 1:37 AM Giacomo Travaglini < giacomo.travagl...@arm.com> wrote: > Hi Gabe, you are definitely right. > The only reason I could think of about why we are checkpointing TLB > entries is because we want to be able to restore the TLB in a wam state. > > In theory you could get away with it in FM by instantiating an empty TLB > which is saving invalid entries (when serializing) and it is restoring > entries > with no effect (when unserializing). > > Having said that I am fine on removing chechkpointing capabilities from > the TLB. > I guess the system will already be in a cold state because of caches. > > Giacomo > ------------------------------ > *From:* gem5-dev <gem5-dev-boun...@gem5.org> on behalf of Gabe Black < > gabebl...@google.com> > *Sent:* 14 January 2020 02:13 > *To:* gem5 Developer List <firstname.lastname@example.org> > *Subject:* Re: [gem5-dev] Stop checkpointing ARM TLB state > > Similarly, the interrupts object checkpoints both an array of bools > (interrupts), and a scalar bit vector (intStatus) which hold the same > information. That information *does* need to be in the checkpoint as far as > I can tell, but it doesn't need to be in there twice. > > Gabe > > On Mon, Jan 13, 2020 at 6:11 PM Gabe Black <gabebl...@google.com> wrote: > > > Hi folks. I'm looking at checkpointing fast models, and one thing I'll > > have to put into the checkpoint is something for the TLBs. I was looking > at > > what they checkpoint, and I think all of it should be removed from > > checkpoints. > > > > As far as I know: > > > > _attr: A cached value which is an implementation detail and not > > architecturally visible. > > haveLPAE: A setting which is not architectural/software visible state. > > directToStage2: Derived state which comes from miscregs. Can be recovered > > on first use by updateMiscRegs if miscRegValid is false (which it is on > > construction). > > stage2Reg, stage2DescReq: Information about in flight translations? These > > should not be in flight when a checkpoint is taken since state should > have > > drained. > > > > TLB entries which can be reloaded in the new TLB. The new TLB won't > > necessarily have the same size as the old one, and so can't necessarily > > have the same table of entries. The entries are not (as far as I know) > > architecturally visible. > > > > All of this state can and should be removed from checkpoints as far as I > > can tell. Please let me know if I'm wrong about some bit of this. > > > > Gabe > > > _______________________________________________ > gem5-dev mailing list > email@example.com > http://m5sim.org/mailman/listinfo/gem5-dev > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. IMPORTANT NOTICE: The contents of > this email and any attachments are confidential and may also be privileged. > If you are not the intended recipient, please notify the sender immediately > and do not disclose the contents to any other person, use it for any > purpose, or store or copy the information in any medium. Thank you. > _______________________________________________ gem5-dev mailing list firstname.lastname@example.org http://m5sim.org/mailman/listinfo/gem5-dev