With this change, when one of the tests fails, it will output a dump
of the trie data structure, making it a little easier to tell what
happened.
Change-Id: I0816ed727ef0b50fefd7ec485356b4fe8790bfe1
Reviewed-on: https://gem5-review.googlesource.com/6267
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
On exiting log types (panic and fatal), the message is set to an
ADD_FAILURE_AT macro, and the test is exited by throwing an otherwise
unexpected exception. On non-exiting log types, the message is sent to
the SUCCEEDED macro which currently doesn't output anything.
Change-Id: I1bb569e6cb8308dbc4c3e04eea7a962bd2b1ddd8
Reviewed-on: https://gem5-review.googlesource.com/6264
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Removed the "verbose" switch which wasn't used.
Replaced the "get(LogLevel)" function with a get for each level. The
parameter was always constant, so we can just call the right function
at the right time.
Made the "exit" behavior of panic/fatal a part of the logging
implementation so that it can be overridden, and corrected a comment
which said that both fatal and panic called ::abort().
Got rid of the printEpilogue function by reworking the print() methods.
The subclasses of Logger can now override a "log" function which takes
a composed message, letting the Logger class centralize how the message
is put together and leaving the actual output mechanism to the
subclass.
Unfortunately there wasn't a way to tell gcc that the panic/fatal
macros wouldn't return, so there needed to be an exit_helper wrapper
function which calls the actual logger exit function. That can be
marked as noreturn, unlike the virtual exit function. If the exit
function does return, the wrapper will call ::abort(), placating gcc
and ensuring that even if exit isn't implemented properly, exit_helper
will still not return. That also provides a handy default
implementation.
Change-Id: I66d0cebd59f1127db980f3b565dbdf60687d8862
Reviewed-on: https://gem5-review.googlesource.com/6263
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Since BaseCPU.createThreads() no longer overrides the BaseCPU.isa
parameter, switch_cpus should have the ISA copied. This fixes a
fatal error in BaseCPU when restoring from a checkpoint.
Change-Id: I4fdcacb76da46bdbe1ce37dcf05c5a6a8a9e5237
Signed-off-by: Austin Harris <austinharris@utexas.edu>
Reviewed-on: https://gem5-review.googlesource.com/6241
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Print faulting instruction for unmapped address panic in faults.cc
and print extra info about corresponding fetched PC in base.cc.
Change-Id: Id9e15d3e88df2ad6b809fb3cf9f6ae97e9e97e0f
Reviewed-on: https://gem5-review.googlesource.com/6461
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change introduces the idea of a SourceFilter which is an object
that can filter a SourceList and which can be composed with other
SourceFilters using | and & operators. This means a filter can be
constructed ahead of time, possibly before all sources have been
discovered, and then later applied to any SourceList necessary.
This change also modifies GTest so that it accepts SourceFilters in
addition to normal source files. These filters will be applied to the
final list of all sources, and the result included in the build for
that test.
By default, gtests will build in all sources tagged with 'gtest lib'.
This change also introduces the keyword argument "skip_lib" which will
exclude those files. They can then be left out entirely, or they can be
re-included as part of a more elaborate filter. That would be useful if
someone wanted to write a unit test for, for instance, the warn, etc.
macros which rely on the gtest logging support. Those classes could
be replaced by something under the control of the unit test, while
still including the rest of the gtest library.
Change-Id: I13a846dc884b86b9fdcaf809edefd57bb4168b8e
Reviewed-on: https://gem5-review.googlesource.com/6262
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Telling scons to build build/${BUILD_OPTS}/unittests.${VARIANT} will
get it to build and run all googletest based unit tests under the
${BUILD_OPTS} build options (ARM, ALPHA, X86, etc.), and compiled with
the flags, etc., for the ${VARIANT} variant (ie. opt, debug, etc.).
This will make it easy to run the unit tests without having to actually
know where they are, what tests are available, etc.
This target is called unittests* and not something based on gtest or
googletest since it's my intention for all unit tests to be based on
googletest, making the distinction unnecessary. Since the target is
essentially part of the external interface for scons, I wanted to name
it something general so it'll be less likely that we have to change it.
Change-Id: I8fdec768d821974309c92a2ce4c96dce7df24fa5
Reviewed-on: https://gem5-review.googlesource.com/6282
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
The FSW and TOP values are technically part of the same register, but
they have very different behaviors. One of them can be renamed and
float along without affecting global state, while the other requires
serialization. They just need to *look* like the same register when
read by the user.
Also, there was a missing break in setMiscRegNoEffect.
Change-Id: If58de0f566f65068208240f4001209fb9e1826d6
Reviewed-on: https://gem5-review.googlesource.com/6441
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
These are really two separate things. Also, while it's realitively
straightforward to write a unit test for the pixel conversion code, the
framebuffer object is serializable and brings in more dependencies.
Change-Id: If954caeb0bfedb1002cfb1a7a115a00c90d56d19
Reviewed-on: https://gem5-review.googlesource.com/6341
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
There were a few places where tags weren't being converted to sets
correctly which unfortunately only manifested when called in certain
ways. This would be a pretty reasonable place to add some python unit
tests...
Change-Id: I87509369b4ec6f702b7521e52bf63701a87ec436
Reviewed-on: https://gem5-review.googlesource.com/6261
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
scons gets upset if two different environments are used to set up a
particular object file. This change adds two dicts to the SourceFile
class, one for static and one for shared object files, which are keyed
off of the appropriate suffix. If a suffix hasn't been set up yet,
a new node of the appropriate type is set up and stored in the cache,
and then whatever is in the cache (new or old) is returned.
Change-Id: Ice4b4fc728b438a4d3316c3ff6667c0480d2a6d7
Reviewed-on: https://gem5-review.googlesource.com/6224
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
This patch adds support for decoding and executing the following ARMv8
cache maintenance instructions by Virtual Address:
* dc civac: Clean and Invalidate by Virtual Address to the Point
of Coherency
* dc cvac: Clean by Virtual Address to the Point of Coherency
* dc cvau: Clean by Virtual Address to the Point of Unification
* dc ivac: Invalidate by Virtual Addrsess to the Point of Coherency
Change-Id: I58cabda37f9636105fda1b1e84a0a04965fb5670
Reviewed-by: Sudhanshu Jha <sudhanshu.jha@arm.com>
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5060
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
This patch adds support for the ARMv7 cache maintenance
intructions:
* mcr dccmvac cleans a VA to the PoC
* mcr dcimvac invalidates a VA to the PoC
* mcr dccimvac cleans and invalidates a VA to the PoC
* mcr dccmvau cleans a VA to the PoU
Change-Id: I6511f203039ca145cc9128ddf61d09d6d7e40c10
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5059
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Ruby has no support for cache maintenace operations. As a workaround,
after printing a warning, we treat them as no-ops in the memory system
and respond immediately without handling them. There should be
workarounds in the memory system already that allow execution to
proceed without the requirement for cache maintenance operations.
Change-Id: I125ee4fa37b674c636d87f2d9205bbc1a74da101
Reviewed-on: https://gem5-review.googlesource.com/5057
Reviewed-by: Jieming Yin <bjm419@gmail.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Systems with atomic cores and the fastmem option enabled bypass the
whole memory system and access the abstract memory directly. Cache
maintenance operations which would be normally handled before the
point of unification/coherence should be ignored by the abstract
memory.
Change-Id: I696cdd158222e5fd67f670cddbcf2efbbfd5eca4
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5054
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Previously responses would either transfer the ownership of the line
or the actual data to the cache that send out the original request.
Cache clean operations are different since they bring neither data nor
ownership. When they are also invalidating the cache that send out the
original request will invalidate any existing copies. This patch
makes the snoop filter handle the cache clean responses accordingly.
Change-Id: I27165cb45b9dc57882526329c62db35f100d23df
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-by: Sudhanshu Jha <sudhanshu.jha@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5053
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
The snoop filter performs sanity checks of the type of packets that
are expected to snoop caches above. Cache maintenace operations are
expected to perform a clean and or invalidate on all caches down to
the specified point of reference and therefore could also generate
snoops.
Change-Id: I7f8fef246a85faa87ccd289c28b49686ed7caa08
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5052
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
A clean packet request serving a cache maintenance operation (CMO)
visits all memories down to the specified xbar. The visited caches
invalidate their copy (if the CMO is invalidating) and if a dirty copy
is found a write packet writes the dirty data to the memory level
below the specified xbar. A response is send back when all the caches
are clean and/or invalidated and the specified xbar has seen the write
packet.
This patch adds the following functionality in the xbar:
1) Accounts for the cache clean requests that go through the xbar
2) Generates the cache clean response when both the cache clean
request and the corresponding writeclean packet has crossed the
destination xbar.
Previously transactions in the xbar were identified using the pointer
of the original request. Cache clean transactions comprise of two
different packets, the clean request and the writeclean, and therefore
have different request pointers. This patch adds support for custom
transaction IDs that by default take the value of the request pointer
but can be overriden by the contructor. This allows the clean request
and writeclean share the same id which the coherent xbar uses to
co-ordinate them and send the response in a timely manner.
Change-Id: I80db76386a1caded38dc66e6e18f930c3bb800ff
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5051
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
To add support for cache maintenance operations (CMOs) in the MSHRs,
this change adds the following functionality:
- If a CMO request hits in the MSHRs, we deferred as we can't
coalesce it with any other requests.
- When we promote any deferred targets, we promote them in order and
stop if we encounter a CMO request. If the CMO request is at the
beginning of the deferred targets list it will be the only promoted
target.
Change-Id: I10d1f7e16bd6d522d917279c5d408a3f0cee4286
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5050
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
This change adds support for maintenance operations (CMOs) in the
cache. The supported memory operations clean and/or invalidate a cache
block as specified by its VA to the specified xbar (PoU, PoC).
A cache maintenance packet visits all memories down to the specified
xbar. Caches need to invalidate their copy if it is an invalidating
CMO. If it is (additionally) a cleaning CMO and a dirty copy exists,
the cache cleans it with a WriteClean request.
Change-Id: Ibf31daa7213925898f3408738b11b1dd76c90b79
Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5049
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
When a response indicates that there are no other sharers of the
block, the cache can promote its copy of the block to writable and
potential service deferred targets even if the request didn't ask for
a writable copy.
Previously, a response would guarantee the presence of the block in
the cache. A response could either be filling, upgrading or a response
to an invalidation due to a pending whole line write. Responses to
cache maintenance invalidations break this assumption. This change
adds an extra check to make sure that the block was already valid or
that the response is filling before promoting the block.
Change-Id: I6839f683a05d4dad4205c23f365a925b7b05e366
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5048
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
This change adds new packet cmds and request flags for cache
maintenance operations.
1) A cache clean operation writes dirty data in the first memory below
the specified xbar and updates any old copies in the memories above
it.
2) A cache invalidate operation invalidates all copies of the
specified block in the memories above the specified xbar
3) A clean and invalidate operation is a combination of the two
operations above
Change-Id: If45702848bdd568de532cd57cba58499e5e4354c
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5047
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Previously, WriteClean packets would always write to the first memory
below unless the memory was unable to allocate in which case it would
be forwarded further below.
This change adds support for specifying the destination of a
WriteClean packet. The cache annotates the request with the specified
destination and marks the packet as write-through upon its
creation. The coherent xbar checks packets for their destination and
resets the write-through flag when necessary e.g., the coherent xbar
that is set as the PoC will reset the write-through flag for packets
to the PoC.
Change-Id: I84b653f5cb6e46e97e09508649a3725d72d94606
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5046
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
This change adds support for creating and handling WriteClean
packets. The WriteClean operation is almost identical to a
WritebackDirty with the exception that the cache generating a
WriteClean retains a copy of the block.
Change-Id: I63c8de62919fad0f9547d412f8266aa4292ebecd
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Curtis Dunham <curtis.dunham@arm.com>
Reviewed-by: Anouk Van Laer <anouk.vanlaer@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/5045
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
It might often be useful to write output to cout when dumping a trie,
but sometimes it might be useful to dump ot to something else like a
string stream instead.
Change-Id: Iaa4ae772c902b7dbc753f320d1a7eb5fcd4a3db3
Reviewed-on: https://gem5-review.googlesource.com/6266
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
These files aren't a collection of miscellaneous stuff, they're the
definition of the Logger interface, and a few utility macros for
calling into that interface (panic, warn, etc.).
Change-Id: I84267ac3f45896a83c0ef027f8f19c5e9a5667d1
Reviewed-on: https://gem5-review.googlesource.com/6226
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
This class isn't referred to outside of misc.hh, and isn't necessarily
useful outside of the particular logging setup implemented in misc.cc.
The Logger class itself is different since it provides a generic
interface that can be used with different logging schemes.
Change-Id: Ibae926fea039d9e3d75a43d97348bc4a3c5d555e
Reviewed-on: https://gem5-review.googlesource.com/6225
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Dumping the structure of the tries being constructed was useful for
debugging when the trie data structure was being developed, but the
output can't be automatically verified easily, and what's considered
correct depends on the specific implementation of the trie itself.
To make some of the earlier tests more meaningful, additional lookups
were added which verified that the correct values were returned when
the nodes of the trie were in particular arrangements.
Change-Id: Ib464ad1804d13fe40882da2190d7bf452da83818
Reviewed-on: https://gem5-review.googlesource.com/6223
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
