Sometimes when using the GuestABI mechanism, gem5 wants to know that a
function was called and with what arguments to do its own processing,
but doesn't want to return its own value since it will still let the
simulated system execute its own function. There are also situations
where gem5 wants to return a value, but not through the normal
mechanism. That happens when, for instance, a gem5 op is triggered by a
memory access, and that access is what should return the value, not a
particular fixed register.
This option is a template parameter rather than a function argument so
that if it's not going to be used, no "Return" type needs to be defined
since it's not present at all in the chain of functions invokeSimcall
expands to.
This will also make it easier to reuse generic ABIs in those situations
without having to make custom wrappers.
Change-Id: I969e78495c8f4e73f4de1a3dfb4d74c9b30f5af5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28288
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
PowerDomains group multiple objects together to regulate their power
state. There are 2 types of objects in a PowerDomain: leaders and
followers. The power state of a PowerDomain is the most performant
power state of any of the leaders. The power state of the followers is
determined by the power state of the PowerDomain they belong to: they
need to be in a power state which is more or equally performant to the
power state of the PowerDomain.
Leaders can be ClockedObjects or other PowerDomains. Followers can
only be ClockedObjects. PowerDomains can be be nested but a
PowerDomain can only be a leader of another PowerDomain, NOT a
follower. PowerDomains are not present in the hierarchy by default,
the user needs to create and configure them in the configuration file.
The user can add an hierachy by setting the led_by parameter. gem5
will then create leaders and followers for each domain and calculate
the allowed power states for the domain.
Objects in a PowerDomain need to have at least the ON state in the
possible_states.
An example of a powerDomain config is:
pd = PowerDomain()
cpu0 = BaseCPU()
cpu1 = BaseCPU()
shared_cache = BaseCache()
cache.power_state.led_by = pd
pd.led_by = [cpu0, cpu1]
This will create a PowerDomain, where the CPUs determine their own
power states and the shared cache (via the PowerDomain) follows those
power states (when possible).
Change-Id: I4c4cd01f06d45476c6e0fb2afeb778613733e2ff
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28051
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit adds the concept of possible power states to the
PowerState SimObject. This is a list of the power states a specific
object can be in. Before transitioning to a power state, a PowerState
object will first check if the requested power states is actually an
allowed state. The user can restricted the power states a
ClockedObject can go to during configuration. In addition, this change
sets the power states, a CPU can be in.
Change-Id: Ida414a87554a14f09767a272b54b5d19bfc8e911
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28050
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit does not make any functional changes but just rearranges
the existing code with regard to the power states. Previously, all
code regarding power states was in the ClockedObjects. However, it
seems more logical and cleaner to move this code into a separate
class, called PowerState. The PowerState is a now SimObject. Every
ClockedObject has a PowerState but this patch also allows for objects
with PowerState which are not ClockedObjects.
Change-Id: Id2db86dc14f140dc9d0912a8a7de237b9df9120d
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28049
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
With the introduction of StatGroups the organization of stats has
changed and the power modeling framework has been broken. This CL uses
the new function Stats::resolve to retrieve pointers to the necesary
stats and use them in the power estimation formulas.
Change-Id: Iedaa97eeddf51f7a0a1f222918715da309943be3
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27892
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 change adds a member function to the Group class that returns a
stat given its name. The function will go through all stats in the
group and its subgroups and will return the stat that matches the
name. For example, if g is the Group system.bigCluster.cpus then a
call to
p = g.resolveStat("ipc")
will return a pointer to the stat system.bigCluster.cpus.ipc.
Change-Id: I5af8401b38b41aee611728f6d1a595f99d22d9de
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27890
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before this change, running:
./build/NULL/gem5.opt configs/example/ruby_mem_test.py -m 20000000 \
--functional 10
would only print warning for memory errors such as:
warn: Read access failed at 0x107a00
and there was no way to make the simulation fail.
This commit makes those warnings into errors such as:
panic: Read access failed at 0x107a00
unless --suppress-func-errors is given.
This will be used to automate MemTest testing in later commits.
Change-Id: I1840c1ed1853f1a71ec73bd50cadaac095794f91
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26804
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
According to the debugging spec (page 47), a debugger can test which
triggers are enabled by writing 0 to TSELECT and reading it back. If a
different value is read, the trigger is not supported.
Therefore, we currently always set a different value to indicate that
we do not support any triggers.
Change-Id: If222e913c4517adb2da4f6f0ffeedb4e4808a586
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25659
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
According to the privileged ISA spec, SEPC[0]/MEPC[0] reads always 0
and SEPC[1]/MEPC[1] reads 0 if the compressed extension is disabled.
Additionally, the compressed extension can only be disabled if the next
instruction is 4-byte aligned.
Change-Id: I590c05e4000b59a5ba283f47933f7a92959d8e38
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25658
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
According to page 57 in the RISC-V manual, CSR accesses "need to be
performed in program order with respect to those instructions whose
execution behavior is affected by the state of the accessed CSR".
Thus, we need to make them SerializeAfter to ensure that the following
instructions are executed with the potential changes to the CSR. In
theory, we could be smarter here by only considering write accesses to
CSRs and considering the following instructions, but for now we simply
serialize for every CSR access.
Change-Id: I69391fccaec31c34d944c55bac2f04d37947ebfe
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25655
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
That is, RISC-V has now a TLB and page table walker for Sv39 paging
according to the privileged ISA 1.11.
Both the TLB and PT walker are based on x86 (the code duplication of the
page table walkers will be reduced by a separate commit).
Change-Id: I5e29683bdd40c0d32c06e4d75a8382bf313f2086
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25647
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 test covers the templates which attempt to classify types, but not the
actual gathering of arguments of distribution of return values. As before, we
can't really use standard C++ to accurately test for HFAs and HVAs, so we stick
with approximating them by detecting arrays of the right types.
For example, I think technically we should also accept a struct with only 4
float members, but c++ templates aren't able to match against types in that way
as far as I know.
Change-Id: I1d7756a964a86c0c5ea13e068a5fc74603e14e30
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28268
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The templates which checked for short vectors, and our approximation of
HFA, HVA and HXA types were not correct. This change actually simplifies
them along with getting them to produce correct results. In the case of
HXA, there was a logic bug where an && was used where an || was
intended.
There may still be bugs in the actual collection of arguments and
setting of return values since those aspects are harder to test.
Change-Id: Ice3177205a98c678ecb43ba600813b3909c44e6b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28267
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Take advantage of string comparisons when looking up what to do with a
given key.
Convert the key_str[12] registers from little endian to host endian.
This matches a corresponding change in the m5 utility to pack the
registers in little endian order, regardless of what the actual guest
endianness is.
Absorb the initparam_keys.hh header into sim/pseudo_inst.cc, and convert
its constants to c++ strings. The constants defined in it might be
useful to guest code calling into the m5 ops, but not for gem5 itself.
By merging them into the .cc file, we also don't have to do any tricks to
try to avoid them having multiple definitions.
Change-Id: I3a450ad7f9c4dca25f79c7835d7f9c167c02ae98
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27230
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
If the first register is all zeroes, it doesn't really matter what the
other register is. If the first register has the entire string, we still
don't care what the other register has in it. There's no reason to
complicate the code with these extra checks.
Change-Id: I22ad521b9ace915ccb75f15934fc6b3d650d5293
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27228
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
SVE half-precision floating-point instructions support only IEEE
754-2008 half-precision format and ignore the value of the FPCR.AHP bit,
behaving as if it has an Effective value of 0.
This patch is addressing this by masking the FPSCR.AHB bit before
passing it to fplib.
Change-Id: I1432fc3f7fefb81445fe042ae7d681f5cec40e64
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28108
Tested-by: kokoro <noreply+kokoro@google.com>
This Patch will fix the alignment problem that appears sometimes
when we try to create a view of 128 bits over the VecRegContainer
object.
That container is initially created as std::array<uint8_t, SIZE>, so
there is no obligation to be aligned to 16 bytes. This patches forces
all containers to be aligned to 16 bytes.
The problem has been observed in the Jira Issue:
https://gem5.atlassian.net/browse/GEM5-320
Change-Id: Id9fdd427bd7a4dc904edd519f31cc29c5b29c5e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27968
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch addresses multiple cases:
- When a controller has read/write permissions while others have read
only permissions, the one with r/w permissions performs the read as
the others may have stale data
- When controllers only have lines with stale or busy access permissions,
a valid copy of the line may be in a message in transit in the network
or in a message buffer (not seen by the controller yet). In this case,
we forward the functional request accordingly.
- Sequencer messages should not accept functional reads
- Functional writes also update the packet data on the sequencer
outstanding request lists and the cpu-side response queue.
Change-Id: I6b0656f1a2b81d41bdcf6c783dfa522a77393981
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22022
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: John Alsop <johnathan.alsop@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
