On 6/22/2023 5:47 PM, Khan Shaikhul Hadi wrote: > Hi Eliot, > Thank you for your detailed answer. > For my current work, I need "CLFLUSH" and "MFENCE" to work properly. For clflush, I was planning to > modify the instructions execution to issue a flush request to the cache and handle the rest using > directory based cache coherence protocol. As flush is treated as a store operation , I don't know > how to receive flush_complete response and clear store buffer in gem5. Do you have any suggestion on > that or which file/function should I look at to get some idea. It's just an ordinary response. An item will not be removed from the store queue until a response comes. The issue at present, as I recall, is that things like an ordinary store get a response from the cache as soon as the cache starts processing the store. In this case you need to defer that response until the request has been processed all the way out to the memory bus, which will send a response back down. I'm not sure what the directory cache coherence protocol has to do with it. (Note: I do *not* use Ruby / Garnet.) > For fence, it's true that X86 ensures total store order but you need a fence to ensure that all the > respective reads on the update read persisted data not volatile data. else  it may result in > inconsistent data upon crash. Based on my understanding, the memory fence does not let other > instructions move forwards unless all the content of the store buffer upto the fence instruction is > cleared.  If the fence does not work properly in gem5, then I want to implement this property. Do > you have any suggestions for me? I'm not well versed with gem5 yet. Sure - if you feel a fence is necessary, use a fence. gem5 implements it by waiting for the store queue to empty (for sfence and mfence) and the load queue to empty (for lfence and mfence). But with eADR as the presumed future, I am not sure of the usefulness of the flushing any more ... Best - EM