Rather than recomputing the reset value every time a system
reset happens (and the ISA::clear method gets called), we
calculate it once and construction time.
We when simply apply the pre-computed reset value to the miscReg
storage, as implemented by a previous patch [1]
[1]: Change-Id: If352501738729927c1c9b300e5b0b8c27ce41b79
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: Iecffff4878217c38707be4ce7d4746ff95a208b4
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70465
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 is fixing read redirection for the MIDR register
in the following ways:
1) Is allowing a virtualization of the register (via VPIDR)
even in secure mode (available with FEAT_SEL2)
2) Is extending this logic to the AArch64 version (MIDR_EL1)
It is also rewriting the base logic using Armv8 terminology
(checking the EL rather than the mode as an example).
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I5cf09240206287cab877ea7ff6e46cf823aa8c35
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70464
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The reset variable in the MiscRegLUTEntry class defines the per-register
reset value. Rather than simply zeroing the misc registers we should
assign them their reset value when clearing them.
As of now the reset variable is unused so using it is functionally
equivalent of calling memset. This will however change once we start
using the reset field
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: If352501738729927c1c9b300e5b0b8c27ce41b79
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70457
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Add an option `exitOnPMUInterrupt` to ArmPMU.
The PMU is often used to identify and demark regions of interest in a
workload intended for sampled simulation (e.g. fast-forward, warm-up,
detailed simulation). Often the PMU is enabled and disabled to demark
these regions, but for some workloads PMU interrupts are used to count
committed instructions directly.
This patch adds the option to exit the simulation loop when a PMU
interrupt is triggered so additional simulation control can be
effected (e.g. stats dump/reset, CPU switch, etc).
Change-Id: Ife02fe8e467dec91a2d4fda3f7dc9540a092f1ec
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69958
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
PMU enables/disables/resets are often used to identify and demark
regions of interest in a workload intended for sampled
simulation (e.g. fast-forward, warm-up, detailed simulation).
This patch adds the option to exit the simulation loop when these
events occur so additional simulation control can be effected (e.g.
stats dump/reset, CPU switch, etc).
Original patch by Nicholas Lindsay <Nicholas.Lindsey@arm.com>.
Updated by Richard Cooper <richard.cooper@arm.com>.
Change-Id: I19be0def8d52fa036a3eee6bafeb63cc1f41694a
Signed-off-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70417
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
1. If the instruction is RV64 only, such as zknd(aes64ds, aes64dsm,
aes64im, aes64ks1i, and aes64ks2), zkne(aes64es, aes64esm,
aes64ks1i, aes64ks2), Zknh(sha512sig0, sha512sig1, sha512sum0,
sha512sum1). The decoder should check rv_type before returning
the instruction.
2. For the Zbkx(xperm8 and xperm4), I seperate them with RV32 and
RV64 respectively, since the xperm function has individual
implement for handling different size of integer.
3. Add the brev8(zbkb) instruction
Change-Id: Id0b7ab2772fd1b21c1ee41075df44a5b6dbe5b47
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66191
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
VOP2 with opcodes 55-61 were added in MI100 and are not in Vega10. This
changeset adds the decodings for these instructions.
The changeset does not implement the instructions, however the fatal
message is much more helpful for debugging compared so a generic
decode_invalid handler.
Change-Id: Ibde0880c35ff915bf8e50772df9ce263e55ca893
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70042
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
The Tarmac v8 Register ("R") record serialisation formats the
underlying 64-bit storage using a format string field width specifier.
This sets a minimum number of hex characters for the value, rather
than a maximum number of characters.
Because of this, when formatting a narrowed view of a larger
register (e.g. the 32-bit w0 view of the 64-bit x0 register), if any
of the upper bits in the underlying storage are set, then the number
of hex characters used will be the minimum number required to
represent the full value. This could result in irregular formatting,
for example an odd number of hex characters.
This irregular formatting can cause parsing warnings or failures in
some Tarmac tools, for example the Arm Tarmac Trace Utilities [1].
This patch modifies the "R" record formatting to first mask off the
upper bits of the value in the underlying storage to ensure that the
correct number of hex characters are used for the size of the register
being serialised.
[1] https://github.com/ARM-software/tarmac-trace-utilities
Change-Id: Idbd80553d3bcdb56fa9edddd48440ab7d4dff073
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69680
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When running 500.perlbench_r of specint 2017, the system will raise an
assertion error. For function bits of src/base/bitfield.hh (line 76),
the parameter First is smaller than Last. This is caused by incorrect
implementation of uqrshl in src/arch/arm/isa/insts/neon64.isa
When shiftAmt equals 0, which mean uqrshl is actually not shift the
value stored in register. sizeof(Element) * 8 - 1 will be smaller than
sizeof(Element) * 8 - shiftAmt, thus will raise the assertion error.
This commit added this special condition.
No Jira issue has been submitted to report this error
Change-Id: I4162ac3ddb62f162619db400f214f33209b23c19
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69318
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The fastmodel simulation would be paused when it hits a breakpoint.
However, the order of stop event happens after the breakpoint event. If
we handle the breakpoint logic in the breakpoint event, it may cause
somehow status unsynchronized. To make the behavior stable, we delay the
breakpoint handle until the simulation stop event called.
Change-Id: I0083561f561af71370ccaa066220b72ed7831b78
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68697
Reviewed-by: Earl Ou <shunhsingou@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We have a setup that requires manual startup of an ssh proxy to
access license server, and without that, gem5 takes about a minute
until the license checkout times out (until then, it's unclear
why nothing is happening).
We asked ARM for a way to decrease timeouts, but that doesn't
seem to be easy to do.
Change-Id: I37b84fd52cb7fb221a9e48dcb52a33a11f4d1580
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68177
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The lock feature will let M mode do memory permission check before
R/W/X data. If the lock bit of pmpicfg set, then the pmpicfg and
pmpaddri will ignore the update value later until CPU reset, and
pmpaddri-1 will ignore if the TOR A field is set.
The following is add in CL:
1. Add condition to run PMP check when any lock bit of pmp tables
is set
2. Add PMP_LOCK bit check when try to update pmpaddr and pmpcfg
3. If there is no PMP entry matches and priviledge mode is M,
no fault generated
4. If the address matches PMP entry, return no fault if priviledge
mode is M and lock bit is not set
For more details about PMP, please see RISC-V Spec Volumn II,
Priviledge Archtecture, Ver 1.12, Section 3.7 Physical Memory
Protection
Change-Id: I3e7c5824d6c05f2ea928ee9ec7714f7271e4c58c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68057
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
According to RISC V spec Volumn I, Section 11.1, the CSR will be
written only if RS1 != 0 or imm != 0. However, after the change
of CL(https://gem5-review.googlesource.com/c/public/gem5/+/67717),
it will cause IllegalInstFault to write status CSR if we don't
change the data.
Example of Instruction Fault for mstatus
```
addi a5, zero, 8
csrc mstatus, a5
```
It will cause instruction fault if mstatus value is 0 due to
"newdata_all == olddata_all". We can just simply check if
the data value is changed out of mask.
Change-Id: Iab4ce7ac646a9105dc04e69c24d084572e28ebab
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67897
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
