Hi Micro, This could be a potential bug in the code. I have opened an issue on the gem5 github based on the above email. The link to the issue is the following: https://github.com/gem5/gem5/issues/484
Regards, Harshil Patel On Wed, Oct 18, 2023 at 1:40 AM Mirco Mannino via gem5-users < gem5-users@gem5.org> wrote: > Hi all, > > I am looking at how the TLB is implemented (riscv ISA). In particular, I > am interested in TLB statistics. > > I noticed that, in the TLB::lokup method ( > https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L109), > there is an input argument (i.e., hidden) which determines whether the TLB > lookup should or should not update TLB statistics. > > In the TLB::doTranslate ( > https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L278) > method, the first lookup updates TLB statistics (i.e., hidden=false). > After a TLB miss, the page walker is invoked and the TLB is looked up > again in the same way. > > The source code is the following: > > TlbEntry *e = lookup(vaddr, satp.asid, mode, *false*); > if (!e) { > Fault fault = walker->start(tc, translation, req, mode); > if (translation != nullptr || fault != NoFault) { > // This gets ignored in atomic mode. > delayed = true; > return fault; > } > e = lookup(vaddr, satp.asid, mode, *false*); > assert(e != nullptr); > } > > > I was wondering if this behavior is correct. > Shouldn't we just count the first TLB miss and use the second TLB access > only to check the correctness of the page walker? Also because surely the > second TLB lookup will definitely result in a TLB hit, otherwise the > simulation is interrupted by an assert. > > Thanks in advance, > Mirco > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org >
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
