On 2/28/2022 5:26 PM, Ethan Bannister via gem5-users wrote: > Hi all, > > I'm currently undertaking a research project where I am implementing fence.t, a proposed fence > instruction for RISC-V allowing ISA access to clearing microarchitectural state, and performing > relatively coarse assessments of performance impact. As a result, I'm trying to implement this > functionality in gem5. > > It would be greatly appreciated if someone more well-versed in gem5's memory model could double > check some of my implementation ideas below, so I don't get caught by any gotchas. > > >From what I can tell, starting with the classic cache, the most sensible way to add this feature > is to extend the packet protocol to memory so it includes a new command, much like FlushReq, but > instead, for example, FullFlushReq. Then modify BaseCache::access to handle this new packet, > functionally handling the flush with BaseCache::memWriteback and then BaseCache::memInvalidate, > perhaps with some simulated latency added for the act of 'flushing' the cache. Since the instruction > would need to act like a memory fence (or at the very least, have no memory requests reordered past > it), the IsWriteBarrier and IsReadBarrier flags would be included in the ISA declaration of the > instruction. > > I may also need to extend Ruby to include a full cache flush instruction - I've seen other threads > on this list with respect to that, but if there are any recent changes or pertinent information then > it'd be greatly appreciated if you could let me know. > > Also - if there are any resources around on gem5's memory modelling that I might've missed, other > than those in the documentation, please let me know as more stuff to aid understanding is definitely > appreciated.
Dear Ethan - I was able to find fence.tso mentioned online, but not fence.t. Anyway, from what I am familiar with in gem5 (and I added some custom cache flushing behavior to an x86 model in the last 6 months), the cache hierarchy itself is coherent. Therefore fences need only to control the interaction between the given cpu (hart in RIC-V terminology, I guess) and the L1 caches. That functionality was already available in the x86 model, and since we're talking about the micro-op engine, my guess is that it's there for RISC-V as well. A full fence wuold merely prevent issuing any ld/st ops until any ones in progress are finished. Again, AFAICT, it's cpu thing, not a cache thing. Best wishes - Eliot Moss _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
