The setup() method of ScalarPrint, inherited from BasePrint, is not
called by its constructor, and is not called on the ScalarPrint "print"
in DistPrint::operator(). This sets most of the values in BasePrint.
Instead, this method sets these values itself based on the values of the
DistPrint itself.
Unfortunately it looks like this method forgot to set enableUnits, which
ends up otherwise uninitialized when the printUnits method is called.
This change fixes that.
Change-Id: Ib1ea78796539f6d9222d19dad597a4e64aa69808
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52483
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
The constructor only initialized two fields, data and _tickInserted. The
print() method at least accesses the coherence status bits, which
valgrind determined were being accessed without being initialized.
This change adds a default initializer to all fields to prevent any
value from flapping around uninitialized.
Change-Id: Ie4c839504d49f9a131d8e3c3e8be02ff22f453a6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52404
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The BaseCache::handleFill function would generate an "old_state" string
unconditionally, just in case it would need to print it out later on in
the function if the Cache debug variable was set. This is very wasteful.
We should only generate that string if we are actually going to use it
later on.
Change-Id: I4a570d1cd2814e5a089eac1233dedd1801d68975
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52405
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When allocating memory with operator new(size_t), we should also delete
that memory with operator delete(). Note that this is a generic form of
new and delete which do not construct an object in the allocated space,
or delete the object when freeing the space.
There were a number of places where we were over-allocating a structure
so that there would be room after it for other data, at least sometimes
to allocate C structures which would have a trailing array of some other
structure with an undefined size. Those structures were then being
stored in a std::unique_ptr with the default deleter, which just calls
full blown delete and not operator delete.
It seems that this is often ok, and I was not able to find anything that
spelled out in bold letters that it isn't. I did find this sentence:
"If the pointer passed to the standard library deallocation function was
not obtained from the corresponding standard library allocation function,
the behavior is undefined."
On this webpage:
https://en.cppreference.com/w/cpp/memory/new/operator_delete
This is a *little* vague, since they might mean you can't mix malloc and
delete, or new and free. Strictly interpretting it though, it could mean
you can't mix operator new with regular delete, or any other mismatched
combination.
I also found that exactly how this causes problems depends on what heap
allocator you're using. When I used tcmalloc, gem5 would segfault within
that library. When I disabled tcmalloc to run valgrind, the segfault
went away. I think this may be because sometimes you get lucky and
undefined behavior is what you actually wanted, and sometimes you don't.
To fix this problem, this change overrides the deleter on all of these
unique_ptr-s so that they use operator delete. Also, it refactors some
code in arch/x86/kvm/x86_cpu.cc so that the function that allocates
memory with operator new returns a std::unique_ptr instead of a raw
pointer. This raw pointer was always immediately put into a unique_ptr
anyway, and, in addition to tidying up the call sights slightly, also
avoids having to define a custom deleter in each of those locations
instead of once in the allocation function.
Change-Id: I9ebff430996cf603051f5baa8708424819ed8465
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52383
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There has been some confusion about usage of 'Optional'. In some areas
of the codebase it was assumed this specifies an optional parameter
(i.e., one which may or may not set, as it has a default value). This is
incorrect. 'Optional[<type>]' is shorthand for 'Union[<type>, None]',
i.e., it is used to state the value may be 'None'. This patch corrects
this throughout the gem5 codebase.
Change-Id: I77a6708dee448e8480870d073e128aed3d6ae904
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52143
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are two kinds of stats in the system. The old one requires an
unique name, while the new one requires an local name. The setName
function has a flag to specify the difference. In the constructor of
InfoAccess, it sets correct flag to the setName function. However, if
you set the name later with the setter, it wouldn't set the flag for
you. This leads the name conflict in new style stats with same local
name. We should also pass the correct flag in the name setter.
Change-Id: I0fcaad3cca65d0f2859c5f6cb28a00813a026a0c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52323
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This was conditioned on the TARGET_ISA being x86 because the code it
replaced was, and that was because the x86 interrupts object had an
extra port that didn't appear for other ISAs. This inconsistency is not
present on either side of this connection, and so we don't need it to be
conditional.
We do, however, need to ensure that the port sends a range change even
if it doesn't have any ranges to send, to satisfy the bookkeeping of the
bus on the other side of the connection. We do that in init, like leaf
devices do.
Change-Id: Idec6f6c5e2cf78b113fb238d0edd2c63d6cd2c23
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52109
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The only difference between the RiscvUart8250 and the regular Uart8250
is that the Riscv version knows how to generate a device tree node
appropriate for use in a Riscv system. This lets us drop the TARGET_ISA
check from that method, since that should be called iff the target
system is Riscv.
Also update the HiFive platform to use the RiscvUart8250 so that it can
continue to generate device trees successfully.
Change-Id: I306596efffed5e5eed337d3db492d2782ebfaa8d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52144
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change adds GUPSGenCore, GUPSGen, GUPSGenEP, and GUPSGenPAR.
GUPSGenCore inherits from AbstractGeneratorCore. It is used for
implementing GUPSGen, GUPSGenEP, and GUPSGenPAR which inherit from
AbstractProcessor. GUPSGen does not implement a multi-core
generator as there are two ways to implement GUPS in parallel.
GUPSGenEP implement GUPS in it Embarrassingly Parallel variant
where multiple instances of GUPS update separate partitions of the
memory. GUPSGenPAR impelements GUPS in its Parallel variant where
multiple generators acccess the same partition of the memory in
parallel.
Change-Id: I57fb327a1ddefb6735ee59a0d7b4609e50af3517
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51613
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This change adds the source code for the PortTerminator SimObject.
It could be used to connect request/response ports in the system
that can not be connected to any other ports. This will prevent
errors caused by orphan ports in the system. As an example if
you have set up a cache hierarchy and do not want to test its
performance in full system mode and want to use PyTrafficGen
instead, your system will end up with an icache or walker ports
that are not connected to anything. In this case, you can use a
PortTerminator to connect the orphan ports in your system.
Change-Id: I5e19cdd3ce064638ffabf29d29225eda77ffc146
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51609
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This simplifies the O3 CPU, and removes special cases around how vector
registers are handled. Now ARM is responsible for maintaining its
different register personalities internally.
Also, this re-establishes the invariant that registers are indexed as
complete, opaque entities with no internal structure, at least as far as
the CPU is concerned.
To make sure the KVM CPU sees the correct state, we need to sync over
the vector registers if we're in 32 bit mode when moving state to or
from gem5's ThreadContext.
Change-Id: I36416d609310ae0bc50c18809f5d9e19bfbb4d37
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49147
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some aspects of the formatting in this file were questionable, like
aligning =s between adjacent lines, although not technically against the
style rules as far as I know.
More strangely though, the whole file used three space indents instead
of the typical four.
Change-Id: I7b60f1978c5b2c60a15296b10d09d5701cf7fa5c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52108
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are called from the ThreadContext, and should not be counted in
the statistics. The (read|set)*Reg methods, aka readIntReg and not
readArchIntReg, are called from the (read|set)*RegOperand methods in the
DynInst, which is the ExecContext implementation when running on O3.
Change-Id: I9abf90fc7bbe80a742325b6dfd3c0e14392af54c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51428
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The x86 KVM CPU had been in the cpu/kvm directory, while the arm CPU was
inconsistently in the arch/arm directory.
This change moves the x86 CPU to be in arch/x86, restoring consistency.
This location will make the KVM support more modular, by not having the
x86 CPU implementation right alongside the generic implementation.
Change-Id: Ia13151f843df8f8877bfef5ff620825877d3dffa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52085
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This virtual method can trivially be shared among different CPUs, making
it unnecessary to cast from a BaseCPU pointer to some more specific CPU
class. The existing similar functions which implement this functionality
are only trivially different, and can be merged into overloads of this
common method.
Noteably this method is not implemented for the MinorCPU which uses the
SimpleThread class, typedef-ed to be MinorThread. If the previous
version of this method had been called on that CPU, it would have
crashed the simulator since a dynamic_cast would have failed. This
doesn't provide an implementation for the MinorCPU, but it also doesn't
make the problem worse, and provides a way to actually implement it some
day.
Change-Id: I23399ea6bbbbabd87e6c8bf7a66d48902745d2cf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52084
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently MOESI_AMD_Base used in VIPER has a CPUonly parameter which
indicates that messages should not try to add GPU SLICC controllers as
destinations. This adds the analogue GPUonly parameter which indicates
that requests should not try to add CPU SLICC controllers.
Also adds an assert to ensure the outgoing message has at least one
destination. This assert would indicate a misconfiguration.
Change-Id: Ibb0affd4606084fca021f0e7c117d4ff8c06d429
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51928
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
The CPUonly variable in MOESI_AMD_Base's Directory indicates that probes
should not be sent to any GPU SLICC controllers as they are not part of
CPU. There is one CPUonly check missing which causes problems in
GPU-only Ruby networks as there is no route to any controllers with that
MachineType. Add a condition to check CPUonly and do nothing in that
case.
Change-Id: I41b6c04feec473e34b04402adfb5978e75b847b6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51927
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
SCons does not use a variable called LDFLAGS, it uses one called
LINKFLAGS. Switch some errant uses to the correct name.
Also, adjust all the other variable names to use LINK, for consistency
and to avoid confusion and avoid mistakes in the future.
Change-Id: I38d40f5231afdf62bcfba04478d403d65e9b1e26
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51987
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This translation generator is returned by the new version of the
TranslateFunctional method which translates a region rather than a
single address. That method is currently virtual with a default
implementation which is not overloaded, but the plan is for the other
MMUs to override that method and inject their own page size minimally.
In the future, the MMUTranslationGen class and the implementations in
the MMUs may be updated so that they can, for instance, handle varying
page sizes across a single translation.
Change-Id: I39479f0f0e8150fc6e3e1a7097a0c8bd8d22d4e0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50759
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The arch implies gem5 lib, and not the other way around. Or in other
words, if, for example, x86 is the ISA, the having the tag 'x86 isa'
would imply that that file also has the tag 'gem5 lib'. Having the tag
'gem5 lib' would not imply 'x86 isa'.
This worked out because when testing for a single tag, we were using
with_any_tags, and 'gem5 lib' would expand to 'gem5 lib' and 'x86 isa'.
Then we would match files which were non-specific and used 'gem5 lib',
or files which had more specifically used 'x86 isa' only. Files which
used, for instance, 'arm isa', would not meet either criteria of the
implied "or".
Change-Id: I301d1bbbbcac1594371584d4b0d5d291b7b77fc4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51827
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
