This should help reduce warning spew when building with newer compilers.
The pybind11::module type has been renamed pybind11::module_ to avoid
conflicts with c++20 modules, according to the pybind11 changelog, so
this CL also updates gem5 source to use the new type. There is
supposedly an alias pybind11::module which is for compatibility, but we
still get linker errors without changing to pybind11::module_.
Change-Id: I0acb36215b33e3a713866baec43f5af630c356ee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40255
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously we use attribute and event for communication between gem5
SimObject to systemC fastmodel sc_module. Creating a base class allows us
to perform casting once and get all the interface required. Also,
instead of warning on attribute not found, we should make simulator
panic if the sc_module does not provide the interface we need.
Change-Id: I91e1036cb792d556dfc4010e7a0f138b1519b079
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40277
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The register cntfrq should be set to system counter frequency.
However, the current fastmodel implementation accidentally set it to
core frequency. This CL removes the wrong implementation, and real
cntfrq setting is performed in the initState.
Change-Id: I6c62822a4fbbcc0c499f79f6003dabb0c133f997
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40276
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Some CSR register is physically shared between different privilige
level. Current implementation of CSR setting only considers to verify
the bits visable in current privilige level, and directly writes the
masked bits back to register. This leads to other bits invisable
to current mode is overwritten and wrong behavior across the modes.
Thus, CSR updating should always keep the bits value for other modes.
e.g. disabling interrupt in S mode with setting
SSTATUS SIE bit will lead to clear MIE bit as well (the interrupt
is disabled unintentionally).
All CSR register sharing same physical register in different mode
may have similar issue. I only fixed some important ones.
The fix is verified in FS.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-860
Change-Id: I34d4766a4b483b5add2c3bbefd28b21b9abf37f6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39036
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The base/refcnt.hh header was not used in base/types.hh at all, and
enum/ByteOrder.hh was there just so other files could find it. Instead,
this change moves enum/Byteorder.hh to sim/byteswap.hh where it's fits
with the purpose of the header.
This change also fixes some style problems with the code in
base/types.hh itself.
Change-Id: I471ae5cb2cca9169ba8616fb8411b40108a3ffb2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39855
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This ABI is effectively used by both the gem5 ops and system calls, in
system calls because it only relies on registers, and in gem5 ops by
inheritance.
Even though these ABIs happen to be the same and were initially defined
to be the same, this change creates a root "reg" ABI which will act as a
root for both so that there isn't an implication that changes to one
should be changes to both.
Change-Id: I8726d8628503be2ad7616a71cc48b66f13e7d955
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39318
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We currently use the traditional SI-like prefixes to represent
binary multipliers in some contexts. This is ambiguous in many cases
since they overload the meaning of the SI prefix.
Here are some examples of commonly used in the industry:
* Storage vendors define 1 MB as 10**6 bytes
* Memory vendors define 1 MB as 2**20 bytes
* Network equipment treats 1Mbit/s as 10**6 bits/s
* Memory vendors define 1Mbit as 2**20 bits
In practice, this means that a FLASH chip on a storage bus uses
decimal prefixes, but that same flash chip on a memory bus uses binary
prefixes. It would also be reasonable to assume that the contents of a
1Mbit FLASH chip would take 0.1s to transfer over a 10Mbit Ethernet
link. That's however not the case due to different meanings of the
prefix.
The quantity 2MX is treated differently by gem5 depending on the unit
X:
* Physical quantities (s, Hz, V, A, J, K, C, F) use decimal prefixes.
* Interconnect and NoC bandwidths (B/s) use binary prefixes.
* Network bandwidths (bps) use decimal prefixes.
* Memory sizes and storage sizes (B) use binary prefixes.
Mitigate this ambiguity by consistently using the ISO/IEC/SI prefixes
for binary multipliers for parameters and comments where appropriate.
Change-Id: I9b47194d26d71c8ebedda6c31a5bac54b600d3bf
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39575
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Those instructions were broken after:
https://gem5-review.googlesource.com/c/public/gem5/+/38381/4
Which is effectively replacing the generic StaticInst src and dest
reg array with an instruction specific one.
The size of the array is evaluated by the ISA parser, which is
counting the operands when parsing the isa code.
Alas, Compare and Swap Pair instructions were augmenting the number
of destination and source registers in the C++ world, which is
invisible to the parser. This lead to an out of bounds access
of the arrays.
This patch is fixing this behaviour by defining XResult2, which
is the second compare/result register for a paired CAS
Change-Id: Ie35c26256f42459805e007847896ac58b178fd42
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39456
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This ABI is also applicable for gem5 ops. Rather than have the gem5 ops
use the syscall ABI, this change exports the syscall ABI and renames it
the "reg" ABI, or in other words an ABI which only uses registers. The
SE workload class then just creates a local name for the "reg" ABI so it
can continue to use it for system calls.
Change-Id: Ifaa38a94d6f0d49b8a2e515e02ce94472a499a00
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39315
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This code was simplified a little while ago, and the wrong variable name
was used in that computation accidentally. Fortunately the "wrong" value
would be too large, and so nothing bad would happen except a pair of
arrays would be overly large in the O3 instruction class.
Change-Id: I9694f1a8c79a62a172ef63bdd2f98fa0ace06acd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38383
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When parsing an ISA description, the InstObjParams class needs to have a
reference to the current parser. It does that by exposing a wrapper to
the description rather than the actual InstObjParams class. That wrapper
injects an additional argument into the InstObjParams constructor.
Originally, the wrapper which injectect the additional argument was a
function which masqueraded as a class. That made it impossible to
subclass InstObjParams.
Instead, this change replaces that function wrapper with a class
wrapper, and injects the extra argument in the __init__ method. This
preserves the fact that the InstObjParams name refers to a class, and
allows any sort of interaction that's normally allowed with a class like
subclassing.
Change-Id: I550ea2e60eadac3c7c0b9afa7d71f4607b49a5d2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39275
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Note:
Some less frequently needed CSR registers (e.g. hpm and pmp registers)
are commented out on purpose. Instructions to add them back are
described in remote_gdb.hh comments. This is to avoid spamming the
remote GDB log when using `info reg all`.
Changes:
1. Added GDB XML files to the ext/ directory (mostly from QEMU)
2. Modified RiscvGdbRegCache
- struct r: added CSR registers
- getRegs, setRegs: reading / setting CSR registers
3. Modified RemoteGDB
- availableFeatures: indicate support for XML registers
- getXferFeaturesRead: return XML blobs
Change-Id: Ica03b63edb3f0c9b6a7789228b995891dbfb26b2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38955
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before the commit, the bootloader had a hardcoded entry point that it
would jump to.
However, the Linux kernel arm64 v5.8 forced us to change the kernel
entry point because the required memory alignment has changed at:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?h=v5.8&id=cfa7ede20f133cc81cef01dc3a516dda3a9721ee
Therefore the only way to have a single bootloader that boots both
pre-v5.8 and post-v5.8 kernels is to pass that information from gem5
to the bootloader, which we do in this patch via registers.
This approach was already used by the 32-bit bootloader, which passed
that value via r3, and we try to use the same register x3 in 64-bit.
Since we are now passing this information, the this patch also removes
the hardcoding of DTB and cpu-release-addr, and also passes those
values via registers.
We store the cpu-release-addr in x5 as that value appears to have a
function similar to flags_addr, which is used only in 32-bit arm and
gets stored in r5.
This commit renames atags_addr to dtb_addr, since both are mutually
exclusive, and serve a similar purpose, DTB being the newer recommended
approach.
Similarly, flags_addr is renamed to cpu_release_addr, and it is moved
from ArmSystem into ArmFsWorkload, since it is not an intrinsic system
property, and should be together with dtb_addr instead.
Before this commit, flags_addr was being set from FSConfig.py and
configs/example/arm/devices.py to self.realview.realview_io.pio_addr
+ 0x30. This commit moves that logic into RealView.py instead, and
sets the flags address 8 bytes before the start of the DTB address.
JIRA: https://gem5.atlassian.net/browse/GEM5-787
Change-Id: If70bea9690be04b84e6040e256a9b03e46710e10
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35076
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ARM reaches in and pads out the source register index list behind the
parser's back to force dest regs to also be sources in case an
instruction fails predication and needs to forward the original register
values. It shouldn't be hacking up these values in that way, but since
it is, this will let it continue to do so while still fitting in the new
system where each instruction allocates its src/dest reg index arrays to
size.
Change-Id: Ia296be9f63123f18f6cdc0d3bb1314d33e759b3a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38380
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
To limit the number of license slots used by SCons when building fast
model components, the fastmodel SConscript set up a group of nodes
which are attached to each simgen run using the SCons SideEffect
method using one of the library files it generates.
To create each unique node, the SCons Value() method was used, passing
it the counter for the loop. In at least version 4 of SCons, what this
ended up doing was setting that library file as a source for each of
the Value() nodes it corresponds to.
That doesn't *seem* like a problem, but then when creating config
include files, files which expose SCons configuration values to C++,
they also create Value() nodes using the value of the config variable.
In cases where that variable is boolean, the value might be 0 or 1.
The result was that the config header depended on Value(0) (for
instance), and then Value(0) depended on a collection of static library
files.
When scons tried to determine whether the config file was up to date,
it tried to check if if its sources had changed. It would check
Value(0), and then Value(0) would try to compute a checksum for its own
source. To do that, it seems to assume that the value can be
interpreted as a string and tries to decode it as utf8. Since the
library is a binary file, that would fail and break the build with a
cryptic message from within the guts of SCons.
To address this, this change replaces the loop index with a call to
object(). Each instance created in that way will be different from
every other, and there will be no way (purposefully or otherwise) to
create a collision with it when creating Value() nodes for some other
purpose.
Change-Id: I56bc842ae66b8cb36d3dcbc25796b708254d6982
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38617
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Reviewed-by: Ahbong Chang <cwahbong@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These values were (seemingly) arbitrarily changed from the original,
non-KVM settings, and no longer matched the comments which were also
copied over. These two bits enable alignment checking on memory accesses
(not normally used on x86), and whether kernel code can write to read
only pages.
Change-Id: I48e560e448e4849607f12e9336d1ab0458ad9407
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38536
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
