On 3/14/2022 5:54 AM, Ethan Bannister wrote:
Dear Eliot,
Sorry for the late reply.
As far as I can tell, fence.t is such an early proposal that its existence is purely in mailing list
discussions and a research paper introducing it here
<https://carrv.github.io/2020/papers/CARRV2020_paper_10_Wistoff.pdf>. Despite being a fence, it's
more of a "temporal state fence", so shared microarchitectural state is supposed to be flushed after
it with the idea that prevents timing attacks across the fence.
As for x86 - I have seen the clflush implementation, but from what I can tell instructions like
wbinvd are not implemented, and hence I was considering extending the protocol rather than issuing a
large amount of line flushes.
Also - it seems RISC-V doesn't seem to have anything like x86's micro-op engine, but instead
Load/Store templates which are provided with specific memory request flags. I was wondering if I
could use this existing structure to implement a cache flush (like wbinvd), but am obviously
unfamiliar with how everything is setup in gem5.
Thanks for the pointer to the research paper!
If you would find useful my changes to the caches for supporting
bulk cache operations like wbinv, I might be able to extract a
patch. It would be a bit of work because I also have stuff for
a different mechanism in there that is part of research maybe
toward a publication, so we're not quite ready to share that part.
Let me know ...
Bet - 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
