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 <[email protected]> on behalf of Gabe Black <[email protected]> Sent: 14 January 2020 02:13 To: gem5 Developer List <[email protected]> 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 <[email protected]> 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 protected] 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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
