On 8/3/2023 11:56 AM, Khan Shaikhul Hadi wrote:
I'm not sure about silent suppression as that flush instruction is called write after write happens to that memory. Fault should arise when a write request is issued. .
This would happen during address translation, which comes before putting something in the write queue, I believe. So my scenario is still plausible, though I do not claim it is right.
Also I checked the packet received in the cpu side port and it receives multiple CacheMaintenance ( CacheClean) requests ( equivalent number of times workload executes clflushopt instruction). So, I'm assuming gem5 handles clflushopt instruction somehow, I just could not track how they are doing it without placing it in the store queue as it will be difficult to simulate the following fence without this.
To get at various things like this, I like to use the Undo Debugger (udb). It's a commercially available time travel debugger, but you can get a free trial and they're also willing to give a free license for academic use. You can find a place where the cache maintenance packet is issued and work backwards from there, possibly going an event at a time to find each prior stage of handling. Best wishes - Eliot Moss _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
