> On April 20, 2013, 1:42 p.m., Ali Saidi wrote: > > i'll push it shortly.
I just realized something else last minute. I don't really know the use case for remap. Should we also invalidate the new_vaddr in the cache? I don't know if a program would ever map onto something else it had already mapped. - Mitch ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1830/#review4267 ----------------------------------------------------------- On April 20, 2013, 1:36 p.m., Mitch Hayenga wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1830/ > ----------------------------------------------------------- > > (Updated April 20, 2013, 1:36 p.m.) > > > Review request for Default. > > > Description > ------- > > Fixes two bugs relating to software caching of PageTable entries. > > The existing implementation can read uninitialized data or stale information > from the cached PageTable entries. > > 1) Add a valid bit for the cache entries. Simply using zero for the virtual > address to signify invalid entries is not sufficient. Speculative, > wrong-path accesses frequently access page zero. The current implementation > would return a uninitialized TLB entry when address zero was accessed and the > PageTable cache entry was invalid. > > 2) When unmapping/mapping/remaping a page, invalidate the corresponding > PageTable cache entry if one already exists. > > > Diffs > ----- > > src/mem/page_table.hh 745e42ffcc80 > src/mem/page_table.cc 745e42ffcc80 > > Diff: http://reviews.gem5.org/r/1830/diff/ > > > Testing > ------- > > > Thanks, > > Mitch Hayenga > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
