----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3401/#review8231 -----------------------------------------------------------
The AMD64 manual does not mention this case something the hardware will do an implicit invalidation of. It seems that just having PDE.PS bit different should trigger a TLB miss and the hardware will walk the page table and replace the TLB entry with the new one. I can understand the intention though I am not sure if the implementation should be done in this way. A more accurate implementation seems to be to update the TLB::lookup function such that it does not return the entry when the logBits are different. - Alexandru Dutu On April 13, 2016, 1:37 p.m., Bjoern A. Zeeb wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3401/ > ----------------------------------------------------------- > > (Updated April 13, 2016, 1:37 p.m.) > > > Review request for Default, Jason Lowe-Power and Steve Reinhardt. > > > Repository: gem5 > > > Description > ------- > > Changeset 11369:52df7c56508b > --------------------------- > x86: fix TLB issue > > In case we have a 4k page mapping and we will later add a 2M > mapping at the same address, we will return the still existing > 4k entry. It is unclear to me why this is, but by deleting any > entry at the same address with a different size we avoid this problem. > > > Diffs > ----- > > src/arch/x86/tlb.cc 2fd64ea0a7cb > > Diff: http://reviews.gem5.org/r/3401/diff/ > > > Testing > ------- > > Observed booting FreeBSD amd64; did a manual run to dump the trie to verify > a few weeks back. > > > Thanks, > > Bjoern A. Zeeb > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
