Fast Models are models written by ARM which emulate different
components of a computer system. They can be combined into small
subsystems and then exported as systemc modules.
To enable this code, you'll need to set USE_ARM_FASTMODEL variable to
true. This CL does not include the fast models themselves, or a license
to use them or the associated tools. To build these fast models, you'll
need to set some scons variables. These variables should be set as
described in the fast model distribution.
* PVLIB_HOME
* MAXCORE_HOME
* ARMLMD_LICENSE_FILE
Some minor patches to source filesdistributed with the fast model code
may be necessary since their use of systemc is not necessarily 100%
standards compliant.
Change-Id: Id53814b95d8aa320da4d4f2159be0736fc12eb73
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20799
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change is based on modify the way we move the AtomicOpFunctor*
through gem5 in order to mantain proper ownership of the object and
ensuring its destruction when it is no longer used.
Doing that we fix at the same time a memory leak in Request.hh
where we were assigning a new AtomicOpFunctor* without destroying the
previous one.
This change creates a new type AtomicOpFunctor_ptr as a
std::unique_ptr<AtomicOpFunctor> and move its ownership as needed. Except
for its only usage when AtomicOpFunc() is called.
Change-Id: Ic516f9d8217cb1ae1f0a19500e5da0336da9fd4f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20919
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This makes the device IntSlavePort calls back into based on a template
parameter so that IntDevice doesn't have to be in the inheritance
hierarchy to use it.
It also makes IntSlavePort inherit from SimpleTimingPort directly,
skipping over MessageSlavePort.
Change-Id: Ic3213edc9c3ed5e506ee1e9f5e082cd47d7c7998
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20820
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Making the implementation of movntps/movntpd consistent with other
non-temporal instructions. We are ignoring the hint here, and
implementing those instructions as cacheable instructions.
This change adds a warning to let user know about this workaround.
Also, this change add the address check for second part of move.
Change-Id: I811652b24cf39ca2f5c5d4c9e9e417f69190b55c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20408
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Data Aborts caused by an atomic instruction have a special rule for
their syndrome:
From a ISS point of view they count as read if a read to that address
would generate a fault; they count as writes otherwise (ISS.WnR bit)
This patch is implementing this in the TLB. For permission faults we
need to explicitly check if a read would trigger a fault
(e.g. checking for the AP bits) since permissions can allow read-only
accesses.
For other MMU exceptions (like translation faults) we are confident the
nature of the access doesn't affect the genration of a fault.
This means that if the access is atomic, we treat it as a read from an
ISS.WnR point of view.
Change-Id: Ia524aa6ae07f81513cdc26c516b5fd9b01a931c3
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20981
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This makes the non-fatal microops advance the PC, and adds missing
functions. The *_once Faults now also can be run once per *something*.
They would previously be run once per Fault invoke function which is
common to all M5WarnOnceFaults. The warn_once microop will now warn
once per message.
Change-Id: I05974b93f3b2700077a411b243679c2ff0e8c2cb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20739
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The SVE patches made registers longer by increasing NumVecElemPerVecReg,
but the GDB XML was not updated to account for that, and as a result GDB
connections were failing with:
Remote 'g' packet reply is too long
This commit introduces NumVecElemPerSimdVecReg which counts only the SIMD
register sizes to get it back working. SVE GDB support is not added here.
Change-Id: I4191b9f1999ae02b0308863db4cc9b5b16a27d6d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20468
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Non-temporal quadword/double-quadword move instructions.
This change ignores the non-temporal hint and instructions are
implemented to send cacheable request to memory.
This would have some "performance" impact (i.e. having some cache
pollution) to get better "correctness" in behavior.
Change-Id: I2052ac0970f61a54bafb7332762debcb7103202d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20288
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Fixes the definition of the RISC-V GDB register cache. The latest
version, of RISC-V gdb, commit c3eb4078520dad8234ffd7fbf893ac0da23ad3c8,
appears to only accept the 32 integer registers + the PC in the 'g'
packet.
This functions with the Linux toolchain (riscv64-unknown-linux-gnu-*),
but works best with the Newlib toolchain (riscv64-unknown-elf-*).
Change-Id: Ie35ea89a45870fb634e6c68236261bde27c86e41
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20028
Reviewed-by: Alec Roelke <alec.roelke@gmail.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Alec Roelke <alec.roelke@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The previous implementation left the registers unmodified which is
technically correct since there is no defined behavior in that case or
a fault to raise. That would make what happened when the following code
consumed the result unpredictable because it would depend on what junk
values were left in the registers. This was originally not a problem
since the space of supported functions were tightly packed, but someone
added a new function with a gap without adjusting this behavior.
This change makes CPUID zero out RAX, RBX, RCX, and RDX when it fails.
That should be more predictable and cause less flakey failures.
Change-Id: If6ffb17c2969d34aff1600c0ffc32333d0b9be44
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20168
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Pouya Fotouhi <pfotouhi@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Adding LD/ST/SWP family of instructions, LD/ST include a set of
operations like ADD/CLR/EOR/SET/UMAX/UMIN/SMAX/SMIN
This commit includes:
+ Instruction decode
+ Instruction functional code
+ New set of skeletons for Ex/Com/Ini/Constructor and declaration.
Change-Id: Ieea8d4256807e004d2f8aca8f421b3df8d76b116
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19812
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
The X86 local APIC doesn't actually use the pio_addr set in the config
and instead computes what address it will respond to based on the
initial ID of the CPU it's attached to. gem5's BasicPioDevice, which
the X86LocalApic class inherits from, does not provide a default value
for that parameter and will complain if *something* isn't set. The
value used, 0x2000000000000000, is a dummy value which is the base of
the region of the physical address space set aside for messages to
local APICs from the CPU and from other local APICs.
Also, the clock for the local APIC's timer is defined to be the bus
clock. The assumption seems to be that this has a 16:1 ratio with the
CPU clock, and I vaguely remember finding that that was more or less
unofficially true, even if it isn't necessary stringently defined to
be that.
Since we were already just assuming that that ratio was correct and
always setting up the local APICs clock that way, we can do that in
the X86LocalApic class definition and remove some special x86 specific
setup that we'd otherwise need for the x86 version of the Interrupt
class. If that's not correct, it can still be overridden somewhere else
in the config.
Change-Id: I50e84f899f44b1191c2ad79d05803b44f07001f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19968
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ARMv8.1-PAN adds a new bit to PSTATE. When the value of this PAN state
bit is 1, any privileged data access from EL1 or EL2 to a virtual memory
address that is accessible at EL0 generates a Permission fault.
This feature is mandatory in ARMv8.1 implementations.
This feature is supported in AArch64 and AArch32 states.
The ID_AA64MMFR1_EL1.PAN, ID_MMFR3_EL1.PAN, and ID_MMFR3.PAN fields
identify the support for ARMv8.1-PAN.
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I94a76311711739dd2394c72944d88ba9321fd159
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19729
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
MSR <pstatefield>, #imm is used for setting a PSTATE field using an
immediate. Current implementation has the following flaws:
* There is no base MSR immediate definition: all the existing
PSTATE fields have a different class definition
* Those implementation make use of a generic data64 base class
which results in a wrong disassembly (pstate register is printed as an
integer register).
This patch is fixing this by defining a new base class (MiscRegImmOp64)
and new related templates. In this way, we aim to ease addition of new
PSTATE fields (in ARMv8.x)
Change-Id: I71b630ff32abe1b105bbb3ab5781c6589b67d419
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19728
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
