As far as I understand, gem5 simulates functionality of clflush instruction for classic cache. Can anyone explain how it do that ? I traced Clflushopt::initiateAcc() function call which eventually calls LSQ::pushRequest() function in lsq.cc. But after completion of translation, it checks request->isMemAccessRequired() and isLoad both of which returns falls. As a result it does not call write() function which should put the instruction in store queue, instead just return inst->getFault(). Without placing this request in the store queue, how does this request reach the cache to invalid the block ? Where gem5 get's timing for this clflush instruction ? Best Shaikhul

On 8/1/2023 5:15 PM, Khan Shaikhul Hadi via gem5-users wrote: > As far as I understand, gem5 simulates functionality of clflush instruction for classic cache. Can > anyone explain how it do that ? > > I traced Clflushopt::initiateAcc() function call which eventually calls LSQ::pushRequest() function > in lsq.cc. But after completion of translation, it checks request->isMemAccessRequired() and isLoad > both of which returns falls. As a result it does not call write() function which should put the > instruction in store queue, instead just return inst->getFault(). > > Without placing this request in the store queue, how does this request reach the cache to invalid > the block ? > Where gem5 get's timing for this clflush instruction  ? My reading of the code suggests that request->isMemAccessRequired() will return true, since this is a request. Things will then move on to do the write. Eventually a suitable packet will be sent to memory (interestingly, it carries no data). HTH Eliot Moss

But my gdb traces showing that request->isMemAccessRequired() is returning false. That's where I'm confused. I'm running this simulation in SE mode. Shaikhul [image: ismemAccessRequired.png] On Tue, Aug 1, 2023 at 5:52 PM Eliot Moss <moss@cs.umass.edu> wrote: > On 8/1/2023 5:15 PM, Khan Shaikhul Hadi via gem5-users wrote: > > As far as I understand, gem5 simulates functionality of clflush > instruction for classic cache. Can > > anyone explain how it do that ? > > > > I traced Clflushopt::initiateAcc() function call which eventually > calls LSQ::pushRequest() function > > in lsq.cc. But after completion of translation, it checks > request->isMemAccessRequired() and isLoad > > both of which returns falls. As a result it does not call write() > function which should put the > > instruction in store queue, instead just return inst->getFault(). > > > > Without placing this request in the store queue, how does this request > reach the cache to invalid > > the block ? > > Where gem5 get's timing for this clflush instruction ? > > My reading of the code suggests that request->isMemAccessRequired() will > return true, since > this is a request. Things will then move on to do the write. Eventually > a suitable packet > will be sent to memory (interestingly, it carries no data). > > HTH > > Eliot Moss >

On 8/2/2023 3:20 PM, Khan Shaikhul Hadi via gem5-users wrote: > > But my gdb traces showing that request->isMemAccessRequired() is returning false. That's where I'm > confused. I'm running this simulation in SE mode. I always deal with FS mode, but I don't think that matters. I wonder if the particular access in question is one to a page not currently mapped. That should result in silent suppression of the flush (no page fault), I believe. EM