On 6/7/2019 8:56 AM, Nikos Nikoleris wrote:
On 07/06/2019 13:40, Eliot Moss wrote:
On 6/7/2019 5:06 AM, Nikos Nikoleris wrote:
Hi Eliot,
gem5 already implements the AArch32 [1] and AArch64 [2] data cache
maintenance instructions by VA. Can you use these, or do you need to add
some custom functionality?
[1]:
https://github.com/gem5/gem5/commit/eeb36e5b6e81c6b9ea6a0c3c97573e762e58ae05#diff-3d3b3ed6a45c8cdc9d511a13c6caaba6
[2]:
https://github.com/gem5/gem5/commit/0c0ccad52595e837301eebcf8597862d9abb4f9c#diff-3d3b3ed6a45c8cdc9d511a13c6caaba6
Thank you, Nikos!
I don't need custom functionality for these, but I am working from
an older snapshot. Given the various _other_ customizations in this
code base, I probably don't want to go overboard in updating Gem5.
I am guessing that I may need more than just these two deltas.
Do you (or does someone) have insight into the minimal set of patches
I need to install in order to gain this particular functionality?
Regards - Eliot
You might be able to add initial support with the following set of
changes - if you can deal with the conflicts - but you will be missing
fixes since then:
b05a197 arch-arm: Change the type of fault for dc ivac instructions
30e9431 arch-arm: Unify permission checks for dc * instructions
f54e874 arch-arm: Check cache maintenance insts for permission faults
c364f58 arch-arm: Turn dc ivac to dc civac when some conditions are met
4d9811c arch-arm: Fix printing of the data cache maintenance instructions
760e2eb arch-arm: Fix cache line size for cache maintenace inst
f4e27c3 arch-arm: Fault when dc ivac is executed from EL0
b72d69c mem-cache: Only pendingModified MSHRs can satisfy CMO snoops
0c0ccad arm: Add support for the dc {civac, cvac, cvau, ivac} instr
eeb36e5 arm: Add support for the mcr dc{ic,i,c}mvac, dccmvau instructions
b9edb35 mem-ruby: Prevent ruby from crashing on CMOs
7d70967 arm: Add CMO support for Non-Cacheable memory
099cb03 cpu: Add support for CMOs in the cpu models
3deff78 mem: Ignore clean requests in the abstract memory
eb27226 mem: Handle CMO responses in the snoop filter
4d8fb74 mem: Allow CMOs as snooping requests in the snoop filter
2f4fb22 mem: Co-ordination of CMOs in the xbar
9a49827 mem: Add support for handling CMOs in the MSHRs
149a501 mem: Add support for CMOs in the cache
2141c29 mem: Promote deferred targets only when the block is valid
e67c97e mem: Add support for cache maintenance operation requests
992fa99 mem: Support for specifying the destination of a WriteClean
2f6d69e mem: Add support for WriteClean packets in the memory system
d8afb86 mem: Add a WriteClean command to the packet class
ad000b5 mem-cache: Add support for checking whether a cache is busy
08e9f25 mem: Add function to check if the slave can receive a timing req
2f468fc mem: Add the notion of point of unification in the coherent xbar
85ef9b0 mem: Align the snoop behavior in the XBar for atomic and timing
8d43922 arch-arm: Allow dc ivac from EL0 when SCTLR_EL1.UCI=1
Thank you, Nikos, for your efforts putting that together for me!
I think it may be easier just to try to upgrade all the way to the
current day, OR to just insert the minimal code necessary for what
I want to do.
I already have a cache flushing mechanism that works, for c, ci, and i,
for data caches by virtual address (which is all I need). It's just
clumsy because I have to write to registers of a funky device we added.
I think I may just try to hook up mcr writes to the three registers
involved, have them send a request to the cache, and when it receives
that request, it can turn around and invoke our existing mechanism
(which may emit write-back requests, etc.).
Best regards! Eliot
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
