> On May 14, 2013, 8:22 a.m., Andreas Hansson wrote: > > src/sim/tlb.hh, line 143 > > <http://reviews.gem5.org/r/1860/diff/1/?file=35366#file35366line143> > > > > Why is this not virtual? Leave all the ones besides x86 use the default > > implementation? > > > > Should it not be const?
The reason it's not virtual at the moment is that most of the translation methods are not (presumably for performance reasons). I don't particularly like that pattern myself since it reduces readability, so I'm happy to change that. I'll make it const, there is no reason for it to change the internal state of the TLB. > On May 14, 2013, 8:22 a.m., Andreas Hansson wrote: > > src/arch/x86/tlb.cc, line 259 > > <http://reviews.gem5.org/r/1860/diff/1/?file=35365#file35365line259> > > > > Do we need to even return anything? Seems it is always NoFault... There are potential future cases where we might want to return faults, so I'd prefer to keep that. It's a sort of second translation after all. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1860/#review4339 ----------------------------------------------------------- On May 2, 2013, 7:01 a.m., Andreas Sandberg wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1860/ > ----------------------------------------------------------- > > (Updated May 2, 2013, 7:01 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9691:653ccf64061a > --------------------------- > arch: Create a method to finalize physical addresses in the TLB > > Some architectures (currently only x86) require some fixing-up of > physical addresses after a normal address translation. This is usually > to remap devices such as the APIC, but could be used for other memory > mapped devices as well. When simulating the CPU using hardware > virtualization, we still need to do these address fix-ups before > inserting the request into the memory system. This patch allows that > code to be used by such CPUs without doing full address translations. > > > Diffs > ----- > > src/arch/alpha/tlb.hh 00dca8a9b560 > src/arch/alpha/tlb.cc 00dca8a9b560 > src/arch/arm/tlb.hh 00dca8a9b560 > src/arch/arm/tlb.cc 00dca8a9b560 > src/arch/mips/tlb.hh 00dca8a9b560 > src/arch/mips/tlb.cc 00dca8a9b560 > src/arch/power/tlb.hh 00dca8a9b560 > src/arch/power/tlb.cc 00dca8a9b560 > src/arch/sparc/tlb.hh 00dca8a9b560 > src/arch/sparc/tlb.cc 00dca8a9b560 > src/arch/x86/tlb.hh 00dca8a9b560 > src/arch/x86/tlb.cc 00dca8a9b560 > src/sim/tlb.hh 00dca8a9b560 > src/sim/tlb.cc 00dca8a9b560 > > Diff: http://reviews.gem5.org/r/1860/diff/ > > > Testing > ------- > > Quick regressions pass (with the exception of 02.insttest and > 40.m5threads-test-atomic where I can't find the binaries) for all supported > architectures. Boots Linux in KVM mode on x86 when applied together with > #1861 (x86 requires APIC remapping magic from the TLB). > > > Thanks, > > Andreas Sandberg > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
