Without setting the correct memory mode the SimpleSwitchableProcessor,
the Minor CPU could not be used as a valid core. This patch corrects
this issue by setting the memory mode to TIMING for Minor CPU cores.
Due to the increasingly complex if-else to determine the memory mode, a
function has been added to CPUTypes to determine what MemMode is
required for each CPUType.
Change-Id: I9384b4a9c0673af34cca04917d763ca45d0ea434
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61535
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The `set_se_binary_workload` function was only setting up the binary to
work on one (the first) processor core. This caused an exception to be
thrown when trying to run an SE mode binary on a multicore system.
Tests have been added to ensure this works as intended.
Note: While this implementation fixes the bugs, it is limited. Future
work is needed to allow for multiprogram workloads.
Change-Id: I33dbaf5015705c299215dc83e8449b16df301cd4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62014
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, when using the switchable processor the first N cores are the
starting cores and the next N cores (e.g., board.processor.core<N+1>)
are the switched in cores. This is confusing when looking at the stats.
This change makes it so that the names of the different processor lists
used in the dictionary when constructing the switchable processor are
used in for the member names as well. This will allow users to have
names like board.processor.ff_cores and board.processor.detailed_cores.
A bit of refactoring of the base processor was required for this.
Change-Id: I244ee5f6080599acb60a777da979da048cf7463e
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62652
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
In commit 83b14e56, getVirtProxy is replaced by inline ternary operators
to decide between FS or SE version. However, dynamic dispatch will not
work in this scenario and the virtual function of SETranslatingPortProxy
will not be called. It may lead to failure in m5op read_file in SE mode.
Change-Id: I9b5f757096cfdbd6fb8bc14b1b0e02245703a0ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62611
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The current MI_example protocol's L1 caches updates the MRU information twice per request on misses -- once when the request reaches Ruby and once when the miss is returned from another level of the memory hierarchy.
Although this approach does not cause any correctness bugs for replacement policies like LRU since this request is the LRU in both cases, it does not work correctly for other policies like SecondChance and LFU, where updating the information twice (for misses) causes them to devolve to LRU.
Note that this was not directly a problem with Ruby previously, because it only supported LRU-based policies that were unaffected by this. However, with the integration of 20879 Ruby now uses the same replacement policies as Classic (which has additional, non-LRU based replacement policies).
This patch resolves this problem by not updating the MRU information a second time for the misses. It has been tested and validated with the replacement policy tests in 20880.
Change-Id: I82a57abf2a16d70820413ba8118378f2e91fd7fb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62232
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
BasicDecode, or decode block templates in general, contains the template
for substituting the return statement returning a StaticInst given a
machine code.
In the case of micro-coding an instruction, this return statement is for
the macro op. Additionally, in gem5 riscv, the spawned micro-ops will be
added in the macro op constructor, which is done in the macro-op
constructor template. Thus, there's no need for having a return statement
for the micro-op.
Currently, there are two return statements in decode-method.cc.inc for
each riscv atomic inst. This change removes one of the two BasicDecode
blocks in atomic inst templates.
This change is expected to a cosmetic change.
Change-Id: Id14bde25d5d3f164b4faafd33bfd5c802a94ca09
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62492
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 BaseCPUProcessor is processor containing BaseCPUCores. This gives
gem5 stdlib users a way to create processors containing BaseCPU
SimObjects. While SimpleProcessor does this by-proxy (the user simply
specifies the desires CPUType and ISA and the correct BaseCPU
instantiation is chosen), this new Processor allows a more raw passing
of BaseCPU objects.
The SimpleProcessor now inherrits from this BaseCPUProcessor to avoid
duplcation of functionality. A refactor to achieve this was moving the
setting of the board's memory mode from the SimpleProcessor's
"incorporate_processor" function to the BaseCPUProcessor's then altering
it to determine MemMode based on BaseCPU subclass rather than the
CPUType.
The tests/gem5/configs/simple_binary_run.py test script has been
extended to create an stdlib run with a BaseCPUProcessor instead of the
SimpleProcessor and tests have been included to ensure the
BaseCPUProcessor functions as intended.
Multiple cores comprising of different BaseCPU types has not been tested
and is not officially supported as of this commit.
Change-Id: I229943ab98ece39646f1b4feb909250bb5c61772
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62353
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This is the last part needed needed to deprecate SimpleCore's
"get_type" function. This "requires_send_evicts" function can be used by
the cache hierarchy to determine whether the core requres sending
evictions from caches.
Change-Id: I4e42d9fcecf0b1c4344f4cd145126a2ea57b7b76
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62352
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This function is useful in various parts of the stdlib to know if a core
is KVM or not as KVM cores requires the simulation to be setup slightly
differently.
Prior to this commit checking whether a core was a KVM core was only
possible via the CPUType which we may not always have.
Change-Id: Ibf6155ad631d5d5e93189d7376f022ea1baa685e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62351
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This separates the idea of a SimpleCore and a BaseCPUCore. A SimpleCore
selects the correct BaseCPU subclass based on user-specified CPUTypes
and target ISA. The new BaseCPUCore type simply wraps any BaseCPU core
for usage in the stdlib.
Much of the code previously handled in SimpleCore has been moved to
BaseCPUCore.
The `cpu_simobject_factory` method has been moved from AbstractCore to
SimpleCore; a more logical location for this function.
Change-Id: I29ce9e381e7d5e8fe57e0db5deb04ad976b7dab9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62292
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This constraint bound us in many ways. There are many cases where we
want a core in a component which does not correspond to a CPUType
enum value.
This refactoring makes it so only SimpleCore utilizes this.
Docstrings have been updated to reflect this change.
Change-Id: I918c73310fc530dd060691cf9be65163cacfffb4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62291
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 patch allows a user to set the "GEM5_USE_PROXY" environment
variable, in the format of "<host>:<port>", to declare a socks5 proxy
server to use when obtaining gem5 resources and the resources.json
file.
Note, this requires the Python SOCKS client module, which can be
installed via `pip install PySocks`.
Change-Id: I13f50d71fb6e0713f6a280ec9d2f0b3049c27eb6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62391
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The previous implementation used the physical memory view when reporting
memory back to GDB. This circumvents MMUs and caches, and leads to wrong
backtraces at the least.
Current architectures support EL3, EL2, and EL1/EL0, and the Iris
interface presents a Msn that corresponds to that (`0x10ff`), see
table "Canonical memory space numbers" in the Iris user guide.
As GDB expects the view of the processor when querying memory (e.g. for
backtraces), this will allow proper backtraces.
Not sure if there is an implicit way of expressing memory attributes
(like in Lauterbach with the access modifiers before address
specifications), or if there is a need to implement special monitor
commands. But for the common use, using `CurrentMsn` should be the
correct choice.
Change-Id: Ibd14c1f94163105539a7fb9132550fe713b5c295
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61951
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Current WFI implementation always put the CPU to sleep even if there's
an pending interrupt. This might cause issue because an interrupt might
happen just before the WFI is executed, and there might not be any
further interrupts to wake the CPU up, so the CPU sleeps indefinitely.
In this CL, we ensure the CPU sleeps only if there's no pending
interrupt at all, regardless whether the interrupt is masked or not. We
intentionally check for masked interrupt as well because a masked
interrupt is also able to wake the CPU up if it occurs after WFI. This
will make the behavior consistent no matter the interrupt comes before
or after WFI.
Change-Id: I74dbc01fed52652101675f1ae8e481b77c932088
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62251
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This implements flattening in the x86 integer and floating point
RegClass-es, as well as adding regName functions for each. These came
from the X86StaticInst::printReg function, and the flattening functions
in the X86ISA::ISA class.
Change-Id: If026e3b44aa64441222451d91e99778f6054d9f0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51228
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
This makes RegIds and the RegClass-es associated with them responsible
for their own flattening. If they don't need to be flattened (a common
case) then they just mark themselves as already flat and that step can
be skipped.
This will also make it possible to get rid of the (get|set)RegFlat APIs,
since if you want to use flattened registers, you'll either have or
create a flattened RegId and pass it into the same (get|set)Reg method.
By making flattening work on RegIds instead of RegIndexes, this will
also make it possible for registers to start out in one RegClass and
move into another one. This would be useful if, for instance, there were
multiple groups of integer registers which had different indexing
semantics, but which should all end up in the same pool for renaming.
For instance, on x86, there are three distinct classes of FP registers.
They are the MMX registers, the pairs of registers which back the XMM
registers, and the X87 registers. Only the last of these needs
flattening. These could all be treated as different RegClass-es
pre-flattening, and could converge on the underlying floating point
register file post-flattening.
Another example in x86 is that some registers can encode that they
should refer to either the first byte of one register, or the second
byte of another register. This only applies to some registers though,
and so only those would need to go through the flattening step.
Another major advantage is that this removes the need for flattening
functions on the ISA object. Having those, and treating the ISA object
as a TheISA::ISA instead of the more generic BaseISA, was done to make
the flattening functions inline, and to make them fold away in cases
where flattening is not necessary. This new scheme isn't *quite* as
streamline as that, since you'll actually need to check if something is
already flattened. You won't, however, need to check what type the
register is and then look up the right flattening function, so that will
likely compensate.
Change-Id: I3c648cc8c0776b0e1020504113445b7d033e665f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51227
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
