This changes fixes two compilation errors when compiling with
FastModels. One is that CurrentMsn should be Iris::CurrentMsn and the
other is that currEL() function needs arch/arm/utility.hh header file.
Test by compiling GEM5 with FastModels:
scons -j64 build/ARM/gem5.opt \
USE_ARM_FASTMODEL=1 \
PVLIB_HOME=... \
MAXCORE_HOME=... \
ARMLMD_LICENSE_FILE=... \
Change-Id: Iabe0a5f25246591f99b57219428b8f87ecd3363c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23924
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
This specialization will correspond specifically with the CortexA76,
instead of specializing the ThreadContext for ARM in general. Some
aspects of this class may need to move into the base IRIS thread
context class, but I'll leave that for a later change.
Change-Id: I9cbe527d36e6fda78601dc39c1963370cfa28b16
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23787
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Fast models are in practice only ARM, so it's not that helpful to have
the ARM-ness factored out. It is, however, helpful to have aspects
which control how gem5 concepts like registers are mapped to fast model
concepts like resources, especially since these mappings may vary from
fast model to fast model.
For instance, it looks like the CortexA76 does not have predicate
vector registers. Rather than make all fast models support or not
support those registers, that can be done on a model by model basis.
Change-Id: I195da4a2f4d2f8593032d0d63e9fd3d20a240d01
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23786
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
This was hardcoded as 5, but should be determined based on the memory
space IDs the fast model returns. What we do now is have a specific
override for ARM (perhaps conceptually the A76) which looks for an
address space called "Current" which seems to work well.
It's possible that the appropriate address space for a different model
might have a different number, or even a different name. This may need
to be further specialized/parameterized in those cases.
Change-Id: Ie1ef99675fd9bccab50b7fc7add16b82a93bd60b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22143
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These use the IRIS breakpoint API to stop the models at the appropriate
points. There seems to be a slightly wonky interaction between
breakpoints and stepping, where if you stop at a breakpoint and then
step, you might end up moving forward more than the number of requested
instructions.
Change-Id: I31f13a120cfc1ad2ec3669ee8befd6d21b328bb2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22122
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The granularity bit should be set since the segment limit should be
interpreted as a number of pages, not bytes.
A comment indicates that NX support is enabled, but the bit wasn't
being set. That's now set to be consistent with FS mode.
The SVME bit is now turned off, since Intel CPUs don't have SVME, and
enabling it apparently makes them upset.
Also disable CR4 bits which enable features neither gem5 nor apparently
my workstation support.
Change-Id: I72d5a07871dede8763b0dd188a52fe5eb6bde6ea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23361
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This will be used by the TLB to do the actual translation.
Unfortunately there isn't a great way to tell what translation type to
use, so we just go through all of them for now. The ARM subclass might
specialize and figure out which address spaces to use based on control
register state.
Change-Id: Id1fcad66554acf9d69af683917b3c2834f825da0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22118
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The logic that determines which syscall to call was built into the
implementation of faults/exceptions or even into the instruction
decoder, but that logic can depend on what OS is being used, and
sometimes even what version, for example 32bit vs. 64bit.
This change pushes that logic up into the Process objects since those
already handle a lot of the aspects of emulating the guest OS. Instead,
the ISA or fault implementations just notify the rest of the system
that a nebulous syscall has happened, and that gets propogated upward
until the process does something with it. That's very analogous to how
a system call would work on a real machine.
When a system call happens, the low level component which detects that
should call tc->syscall(&fault), where tc is the relevant thread (or
execution) context, and fault is a Fault which can ultimately be set
by the system call implementation.
The TC implementor (probably a CPU) will then have a chance to do
whatever it needs to to handle a system call. Currently only O3 does
anything special here. That implementor will end up calling the
Process's syscall() method.
Once in Process::syscall, the process object will use it's contextual
knowledge to determine what system call is being requested. It then
calls Process::doSyscall with the right syscall number, where doSyscall
centralizes the common mechanism for actually retrieving and calling
into the system call implementation.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I937ec1ef0576142c2a182ff33ca508d77ad0e7a1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23176
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
In Alpha and MIPS, the argc and argv values should be in what happens
to be the first and second syscall argument registers, but that's not
by definition. The process objects of both those ISAs know what
registers to use intrinsically, so there's also no reason to call out
to a helper method which acts as a part of the Process's interface to
the rest of gem5.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: Id8fa38ab1fc2ac6436e94ad41303439973fded10
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23173
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Sometimes NumFloatV7ArchRegs is used to specify the maximum number of
AArch32 floating point registers. Sometimes it is just used for indexing
a free register storage to be used by microcode. In that scenario,
VecSpecialElem should be used, which is a index to the first available
non architectural register for floating point.
Change-Id: I4e84740701f0e7041cf1acad2afed471361c423a
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/+/23107
Tested-by: kokoro <noreply+kokoro@google.com>
The generic VLdmStm class (modelling A32 VLDM/VSTM) is handling a wrong
register list in a inconsistent way. Some instructions are opting
for being decoded as Unknown, while others handle it inside the
macro instruction constructor by manually adjusting the reglist.
Those are two valid implementation of the CONSTRAINT UNPREDICTABLE
behaviour (1 and 3):
"If regs > 16 || (d+regs) > 32 , then one of the following behaviors must
occur:
1) The instruction is UNDEFINED .
2) The instruction executes as NOP .
3) One or more of the SIMD and floating-point registers are UNKNOWN . If
the instruction specifies writeback, the base register becomes UNKNOWN .
This behavior does not affect any general-purpose registers."
This patch unfies the behaviour by always opting for option 1) over 3)
Change-Id: I4f98409243d5a2ec64113fe9c87e961a391abe94
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23106
Tested-by: kokoro <noreply+kokoro@google.com>
This is putting some order in the constants definition, respecting
the description which divides:
* Constants Related to the number of registers
(example: const int NumFloatRegs = 0)
from:
* Semantically meaningful register indices (to indicate special
registers)
(example: const int INTRLVREG0 = NumVecV8ArchRegs + NumVecSpecialRegs)
Change-Id: I1760b7f786b6f6becbe8ab445e65fc3fa17206cb
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/+/23104
Tested-by: kokoro <noreply+kokoro@google.com>
In an earlier patch, the FCSR was split into its two components, FRM and
FFLAGS, causing explicit writes to FCSR to incur two CSR writes. With
the O3 CPU model, which defers them both to later, this creates a bug
where an assertion that the number of CSR writes must be less than
MaxMiscDestRegs fails because that constant is 1. This patch sets it to
2 so the O3 CPU is compatible with this scheme.
Change-Id: Ic3413738c4eebe9f127980d0d0af5033d18468e7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23220
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Endianness transformation was moved from the CPU into this method,
making the "inst" parameter guest endian instead of host endian. The
emi member of the decoder was set using the betoh method, ensuring that
it was still stored in host order. Unfortunately, the "inst" parameter
was used in some places when setting up the rest of emi.
This change replaces those uses of inst with emi.
Change-Id: I0c7f9a1833db4b64fc1a5015cf10f6ba3f7c26a0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23163
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
For compressed instruction c.lui, the 6-bit immediate is left-shifted by 12
bits in decoding. While the original Gem5 gives the left-shifted value
directly in disassembly.
This patch fixes the problem by adding a new template CILuiExecute to
resume the immediate before outputting it in disassembly.
Note: The immediate is sign-extended to 20-bit to be compatible with GCC.
Change-Id: If73f72d3e8f85a8b10ce7a323379d8ad6c4c3085
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22567
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The methods which set or get an attribute from the virtual GIC use a
shift constant which is 32, but they store their result in a 32 bit
variable and, according to clang, are used to shift 32 bit inputs. This
is undefined behavior in terms of the shift, and will truncate off the
value regardless.
Change-Id: Ie9543ab9e6e1d5f86317a9210d220928b23ffaf8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23129
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
The "shamt" in integer shift immediate instructions is an unsigned
immediate encoded in bits[25:20]. While the original Gem5 uses bits[31:20]
as an int64_t. This patch fixes the problem by:
- Adding a new parameter "imm_code" for format IOp and use the correct
bitfields SHAMT5 or SHAMT6 to assign "imm_code" for each instruction.
- Use uint64_t instead of default int64_t to assign parameter "imm_type"
of format IOp.
The instructions affected include:
- Shift Left Logical Immediate, slli
- Shift Right Logical Immediate, srli
- Shift Right Arithmetic Immediate, srai
- Shift Left Logical Word Immediate, slliw
- Shift Right Logical Word Immediate, srliw
- Shift Right Arithmetic Word Immediate, sraiw
Change-Id: Iad34ccd036c11630409f84f6de2b939224e100e6
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22563
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The original Gem5 does not give correct disassembly for instruction fence
and fence.i. This patch fixes the problem by adding two bitfields PRED and
SUCC and a new format FenceOp and a template FenceExecute, in which
operands are generated based on PRED and SUCC in the disassembling
function.
Change-Id: I78dbf125fef86ce40785c498a318ffb1569da46c
Signed-off-by: Ian Jiang <ianjiang.ict@gmail.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22569
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Software such as Trusted Firmware-A checks the MIDR register
to identify which core model is present in the platform.
The previous default value referred to a Cortex-A15 Armv7-A
processor, however when AArch64 is enabled, an Armv8 processor
is expected.
This patch assigns the Cortex-A57 MIDR if AArch64 is enabled.
Change-Id: Id1677a77d2f04843423f7b013405445f3d253399
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22846
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
