I found it, the buildInst method puts the instruction in the decoder queue:
1069 <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#1069> toDecode <http://grok.gem5.org/source/s?defs=toDecode&project=m5>->insts <http://grok.gem5.org/source/s?defs=insts&project=m5>[toDecode <http://grok.gem5.org/source/s?defs=toDecode&project=m5>->size <http://grok.gem5.org/source/s?defs=size&project=m5>++] = instruction <http://grok.gem5.org/source/s?defs=instruction&project=m5>; -Andrea On Fri, Oct 28, 2011 at 8:44 AM, Korey Sewell <[email protected]> wrote: > I took a quick look at this code and didnt see anything obvious (although > the translation additions are more recent than I've been paying close > attention). > > Gabe? > > On Wed, Oct 26, 2011 at 2:43 PM, Andrea Pellegrini < > [email protected]> wrote: > >> Hi all, >> I have a hard time understanding how ITLB misses and page faults are >> handled in gem5. >> I am working on X86, System call emulation. >> >> From what I gathered so far, a TLB miss causes a translation event that >> calls: >> >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#613>DefaultFetch >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#DefaultFetch><Impl >> <http://grok.gem5.org/source/s?defs=Impl&project=m5>>::finishTranslation >> <http://grok.gem5.org/source/s?refs=finishTranslation&project=m5>(Fault >> <http://grok.gem5.org/source/s?defs=Fault&project=m5> fault >> <http://grok.gem5.org/source/s?refs=fault&project=m5>, RequestPtr >> <http://grok.gem5.org/source/s?defs=RequestPtr&project=m5> mem_req >> <http://grok.gem5.org/source/s?refs=mem_req&project=m5>) >> >> >> In case of page fault, the code executed is the following: >> >> DPRINTF <http://grok.gem5.org/source/s?defs=DPRINTF&project=m5>(Fetch >> <http://grok.gem5.org/source/s?defs=Fetch&project=m5>, "[tid:%i] Got back >> req with addr %#x but expected %#x\n", 664 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#664> >> mem_req <http://grok.gem5.org/source/s?defs=mem_req&project=m5>->getVaddr >> <http://grok.gem5.org/source/s?defs=getVaddr&project=m5>(), memReq >> <http://grok.gem5.org/source/s?defs=memReq&project=m5>[tid >> <http://grok.gem5.org/source/s?defs=tid&project=m5>]->getVaddr >> <http://grok.gem5.org/source/s?defs=getVaddr&project=m5>()); 665 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#665> // >> Translation faulted, icache request won't be sent. 666 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#666> delete >> <http://grok.gem5.org/source/s?defs=delete&project=m5> mem_req >> <http://grok.gem5.org/source/s?defs=mem_req&project=m5>; 667 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#667> memReq >> <http://grok.gem5.org/source/s?defs=memReq&project=m5>[tid >> <http://grok.gem5.org/source/s?defs=tid&project=m5>] = NULL >> <http://grok.gem5.org/source/s?defs=NULL&project=m5>; 668 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#668> 669 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#669> // Send >> the fault to commit. This thread will not do anything 670 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#670> // until >> commit handles the fault. The only other way it can 671 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#671> // wake >> up is if a squash comes along and changes the PC. 672 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#672> TheISA >> <http://grok.gem5.org/source/s?defs=TheISA&project=m5>::PCState >> <http://grok.gem5.org/source/s?defs=PCState&project=m5> fetchPC >> <http://grok.gem5.org/source/s?refs=fetchPC&project=m5> = pc >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#pc>[tid >> <http://grok.gem5.org/source/s?defs=tid&project=m5>]; 673 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#673> 674 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#674> DPRINTF >> <http://grok.gem5.org/source/s?defs=DPRINTF&project=m5>(Fetch >> <http://grok.gem5.org/source/s?defs=Fetch&project=m5>, "[tid:%i]: >> Translation faulted, building noop.\n", tid >> <http://grok.gem5.org/source/s?defs=tid&project=m5>); 675 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#675> // We >> will use a nop in ordier to carry the fault. 676 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#676> >> DynInstPtr <http://grok.gem5.org/source/s?defs=DynInstPtr&project=m5> >> instruction <http://grok.gem5.org/source/s?refs=instruction&project=m5> = >> buildInst >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#buildInst>(tid >> <http://grok.gem5.org/source/s?defs=tid&project=m5>, 677 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#677> >> StaticInstPtr >> <http://grok.gem5.org/source/s?defs=StaticInstPtr&project=m5>(TheISA >> <http://grok.gem5.org/source/s?defs=TheISA&project=m5>::NoopMachInst >> <http://grok.gem5.org/source/s?defs=NoopMachInst&project=m5>, fetchPC >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#fetchPC>.instAddr >> <http://grok.gem5.org/source/s?defs=instAddr&project=m5>()), 678 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#678> >> NULL <http://grok.gem5.org/source/s?defs=NULL&project=m5>, fetchPC >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#fetchPC>, fetchPC >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#fetchPC>, *false*); >> 679 <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#679> 680 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#680> >> instruction >> <http://grok.gem5.org/source/s?defs=instruction&project=m5>->setPredTarg >> <http://grok.gem5.org/source/s?defs=setPredTarg&project=m5>(fetchPC >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#fetchPC>); 681 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#681> >> instruction >> <http://grok.gem5.org/source/s?defs=instruction&project=m5>->fault >> <http://grok.gem5.org/source/s?defs=fault&project=m5> = fault >> <http://grok.gem5.org/source/s?defs=fault&project=m5>; 682 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#682> >> wroteToTimeBuffer >> <http://grok.gem5.org/source/s?defs=wroteToTimeBuffer&project=m5> = *true*; >> 683 <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#683> 684 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#684> DPRINTF >> <http://grok.gem5.org/source/s?defs=DPRINTF&project=m5>(Activity >> <http://grok.gem5.org/source/s?defs=Activity&project=m5>, "Activity this >> cycle.\n"); 685 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#685> cpu >> <http://grok.gem5.org/source/s?defs=cpu&project=m5>->activityThisCycle >> <http://grok.gem5.org/source/s?defs=activityThisCycle&project=m5>(); 686 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#686> 687 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#687> >> fetchStatus <http://grok.gem5.org/source/s?defs=fetchStatus&project=m5>[tid >> <http://grok.gem5.org/source/s?defs=tid&project=m5>] = TrapPending >> <http://grok.gem5.org/source/s?defs=TrapPending&project=m5>; 688 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#688> 689 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#689> DPRINTF >> <http://grok.gem5.org/source/s?defs=DPRINTF&project=m5>(Fetch >> <http://grok.gem5.org/source/s?defs=Fetch&project=m5>, "[tid:%i]: Blocked, >> need to handle the trap.\n", tid >> <http://grok.gem5.org/source/s?defs=tid&project=m5>); 690 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#690> DPRINTF >> <http://grok.gem5.org/source/s?defs=DPRINTF&project=m5>(Fetch >> <http://grok.gem5.org/source/s?defs=Fetch&project=m5>, "[tid:%i]: fault (%s) >> detected @ PC %s.\n", 691 >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#691> >> tid <http://grok.gem5.org/source/s?defs=tid&project=m5>, fault >> <http://grok.gem5.org/source/s?defs=fault&project=m5>->name >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#name>(), pc >> <http://grok.gem5.org/xref/m5/src/cpu/o3/fetch_impl.hh#pc>[tid >> <http://grok.gem5.org/source/s?defs=tid&project=m5>]); >> >> From this snapshot looks like the fault will be carried on to the commit >> stage by a noop. However, I cannot understand where such instruction is sent >> to, as the object "instruction" is not stored anywhere else. >> Can anybody help me understand how such traps are supposed to work? >> >> Thank you very much, >> -Andrea Pellegrini >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > -- > - Korey > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
