Hi Rodolfo, I'm glad to hear you were able to solve your issue. Just curious, did you find that the current evictionCallback interface was sufficient for your use case?
Brad -----Original Message----- From: gem5-dev [mailto:[email protected]] On Behalf Of Rodolfo Guilherme Wottrich Sent: Friday, August 19, 2016 10:46 AM To: gem5 Developer List <[email protected]> Subject: Re: [gem5-dev] Fault handling issue For future reference: my problem was not that subsequent instructions would not squash. I missed out on the fact that the store queue's behaviour is asynchronous and although the instructions had been committed many cycles before, the requests would still be in the store queue to be consumed by the cache. It was only a matter of forcefully removing the stores for the LSQ and it worked. --- Rodolfo Wottrich On Mon, Aug 15, 2016 at 5:24 PM, Rodolfo Guilherme Wottrich < [email protected]> wrote: > Hi Fernando, > > Thank you for the suggestion. Yes, I have tried that, but the problem > is that no similar faults take happen, especially in SE mode. > I wonder if it may be the case of some squashing function call that I > am missing. > > Does anybody have experience with squashing instructions in the commit > stage? > > > --- > Rodolfo Wottrich > > On Mon, Aug 8, 2016 at 10:08 AM, Fernando Endo > <[email protected]> > wrote: > >> Hello, >> >> Probably I can't technically help you here, but have you considered >> observing the simulator behavior when similar faults happen? For >> example, simulate a program that access an invalid address and enable >> all related debug flags to track it (--debug-flags option). >> >> Hope it helps, >> >> -- >> Fernando A. Endo, Post-doc >> >> INRIA Rennes-Bretagne Atlantique >> France >> >> >> 2016-08-03 3:30 GMT+02:00 Rodolfo Guilherme Wottrich <[email protected]>: >> >> > Hello, >> > >> > I would like to request some assistance if possible. For my PhD >> > work, I need to be able to trigger a CPU fault when a particular >> > condition in >> the >> > L1 cache controller is met. I am using an o3 x86 CPU and Ruby in SE >> mode. >> > >> > I have come to a partial solution to the problem, based on a patch >> > I >> found >> > which dealt with a similar situation. That involves creating a new >> > Sequencer callback function that is used only at that specific >> situation in >> > the cache controller which triggers a sequence of actions that >> eventually >> > lead to a Fault object being instantiated in the LSQ and in the >> > commit stage of the pipeline. >> > >> > The problem is that although the Fault and its handling are "working" >> > (control flow changes and registers are updated as they should), >> subsequent >> > requests still keep being received by the cache in the mandatory >> > queue >> from >> > the instructions following the offending one. Those instructions >> > should have been cancelled as in a branch misprediction and their >> > requests >> should >> > have been removed from the LSQ to avoid inconsistency. >> > >> > Can anybody think of why I am having such a problem/how can I solve it? >> I >> > can provide specifics once the discussion starts. >> > >> > Thank you in advance. >> > Cheers, >> > >> > --- >> > Rodolfo Wottrich >> > _______________________________________________ >> > gem5-dev mailing list >> > [email protected] >> > http://m5sim.org/mailman/listinfo/gem5-dev >> > >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
