Hi Brad and Bjoern, I apologize for taking long to answer. I had the thread bypass my inbox, and I did not see the responses...
Wrt evictionCallback, honestly, I do not understand it very well and I think it would not suit my needs (but that's because my architecture is indeed fairly experimental). To remove requests from the store queue, I actually created a flag in LSQUnit that changed the behaviour of LSQUnit<Impl>::squash in my particular situation: storesToWB is decremented even if the storeQueue's entry canWB (thus, effectively removing the undesirable requests of already committed instructions). The flag is set and LSQUnit<Impl>::squash is called right after I create a fault in the handling of the pkt that arrives from the cache indicating that the squash should happen. The fault is a custom one that I created, inheriting from X86Fault, whose "invoke" function works as a handler in hardware (to overwrite registers, change the control flow, etc). Does that make sense? I know that this is more like a hack to have my implementation work than an actual improvement to the simulator, but in my defense, I am dealing with experimental stuff that does not represent any particular real architecture, and my changes would not make it to the tree anyway. =) I can provide more details upon request. Cheers, --- Rodolfo Wottrich On Mon, Aug 22, 2016 at 5:39 AM, Bjoern A. Zeeb < [email protected]> wrote: > On 19 Aug 2016, at 17:45, Rodolfo Guilherme Wottrich wrote: > > Hi Rodolfo, > > how did you solve this (code wise). I am trying to hunt down an > undelivered Page Fault on x86 FS and another problem only showing up as I > add more caches (e.g., a L2) and I am just curious about all kinds of x86 > problems other people see and their code changes to fix things. > > Thanks, > Bjoern > > > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
