Information about what kernel to load and how to load it was built
into the System object and its subclasses. That overloaded the System
object and made it responsible for too many things, and also was
somewhat awkward when working with SE mode which doesn't have a kernel.
This change extracts the kernel and information related to it from the
System object and puts into into a OsKernel or Workload object.
Currently the idea of a "Workload" to run and a kernel are a bit
muddled, an unfortunate carry-over from the original code. It's also an
implication of trying not to make too sweeping of a change, and to
minimize the number of times configs need to change, ie avoiding
creating a "kernel" parameter which would shortly thereafter be
renamed to "workload".
In future changes, the ideas of a kernel and a workload will be
disentangled, and workloads will be expanded to include emulated
operating systems which shephard and contain Process-es for syscall
emulation.
This change was originally split into pieces to make reviewing it
easier. Those reviews are here:
https: //gem5-review.googlesource.com/c/public/gem5/+/22243
https: //gem5-review.googlesource.com/c/public/gem5/+/24144
https: //gem5-review.googlesource.com/c/public/gem5/+/24145
https: //gem5-review.googlesource.com/c/public/gem5/+/24146
https: //gem5-review.googlesource.com/c/public/gem5/+/24147
https: //gem5-review.googlesource.com/c/public/gem5/+/24286
Change-Id: Ia3d863db276a023b6a2c7ee7a656d8142ff75589
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26466
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
getArmSystem is the building block for a lot of ArmSystem getters
a client can use to check for a specific feature.
This method is called very often during simulation and it is basically
casting a System pointer into an ArmSystem pointer.
To do so, it is using dynamic casting to check if the system is really
an ArmSystem. This is very expensive and usually not needed.
The only chance arm code would use a non ArmSystem is when in SE mode.
But if that's the case, we can just replace the assertion with a
assert(FullSystem).
Testing Linux boot with this patch provides a speedup of nearly 2x!
(atomic mode).
This is partially related to:
JIRA: https://gem5.atlassian.net/browse/GEM5-337
Since the PAuth patch changed the purifyTagged helper (on the critical
path of simulation) to rely more heavilly on getArmSystem (via
ArmSystem:: static methods)
Change-Id: Idbf079548ffe03513b4fc58c76f0d69613952a50
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25964
Tested-by: kokoro <noreply+kokoro@google.com>
The version of vtophys which didn't take a ThreadContext had only been
implemented on Alpha which has since been removed, so this version of
the function was completely unimplemented and never used.
This change also gets rid of the dbg_vtophys which was sometimes
implemented but also never used, and takes the opportunity to fix up
some style problems in some of the vtophys arch files.
Change-Id: Ie10f881f8ce08c7188e71805357cf3264be4c81a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26224
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The new local access mechanism installs a callback in the request which
implements what the mmapped IPR was doing. That avoids having to have
stubs in ISAs that don't have mmapped IPRs, avoids having to encode
what to do to communicate from the TLB and the mmapped IPR functions,
and gets rid of another global ISA interface function and header files.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I772c2ae2ca3830a4486919ce9804560c0f2d596a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23188
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently the System class has a mechanism to wait for a GDB connection
for each CPU which has requested it through one of its parameters.
Unfortunately, not every thread context/CPU will be ready for GDB at
that point, particularly considering that in an FS simulation the
kernel won't have been read so there will be no symbols, none of the
registers or the entry point will have been set.
Also in the fast models, the CPUs haven't had a chance to initialize
themselves enough by that point to respond to the API calls which are
used to implement GDB support.
Change-Id: If27cb3e0259a1f67599ab0493695b2f8af640d8e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24963
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When defining a static constexpr variable in C++11, it is still
required to have a separate definition someplace, something that can
be particularly problematic in template classes. C++17 fixes this
problem by adding inline variables which don't, but in the mean time
having a static constexpr value with no backing store will, if the
compiler decides to not fold away the storage location, cause linking
errors.
This happened to me when trying to build the debug build of ARM just
now.
By turning these expressions into static inline functions, then they
no longer need definitions elsewhere, still fold away to nothing, and
are compliant with C++11 which is currently the standard gem5 expects
to be using.
Change-Id: I647d7cf4a1e8de98251ee9ef116f007e08eac1f3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24964
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
gem5 does not historically distinguish between address spaces when
interacting with gdb, and gdb doesn't really give it any address space
information to work with. To ensure we catch whatever address space
we might be in by the time we get to the interesting address, we'll set
a breakpoint in all possible address spaces simultaneously with the
expectation that we'll hit one of them.
Change-Id: I9f4b93d04914db7a3c42be6236a523d35194afda
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25268
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
When the last event is removed from a breakpoint, then the breakpoint
itself is uninstalled from IRIS, and the list is deleted. Even though
the list has been traversed and so we don't lose track of any other
events that need to be processed, we also still need to check against
end() to see that we're done. If that now freed memory gets
overwritten, then we won't see the end and will wander right off the
end of the list into nonsense.
This change modifies the breakpoint info tracking structure to keep a
shared pointer to the event list. The pointer will still automatically
manage the list's memory so that it doesn't leak, and it won't get
deleted out from under us as we're iterating through it.
Change-Id: I5ad0f095d07f0a3a5cce9c10f03121827a674c33
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24965
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
This only seems to be used from outside of the CPU when resetting state
at the start of execution. Since this state is already reset in
fast model, we can mostly ignore that call for now.
When more accessors are implemented, this function can be use them to
clear registers like it would on other thread contexts.
Change-Id: I5146273387ec17987770abc67f6f426c4480e0b9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24967
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
ArmISA::clear resets the value of the architecture registers. Some of
these are cached in ArmTLB, including SCTLR. This patch invalidates the
cached copies on clear; this fixes a bug when resetting CPU cores by which
the cached SCTLR was used and SCTLR.M was set, resulting in non-arch
compliant reset behaviour and a PA being treated as a VA on translation.
Change-Id: I8d4eeeaf807325bd7b300a7a317abfa40ad23c87
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25466
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is achieved by using keyword arguments to improve readibility.
Some of the building helpers are using native types and can be annoying
for a reader to understand what those sequences of number and boolean
mean. It is also easier in this way to commit mistakes.
Change-Id: I63081d09a1f621550c5b6522b8107f349939b21d
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24044
Tested-by: kokoro <noreply+kokoro@google.com>
These instructions were extracting a bitfield by masking it, but then
didn't shift the bit into the correct position. They were then
comparing it with 1, which clang 11 correctly complained would always
be false. That warning became an error which broke the build.
This fixes that problem by switching that line and the few surrounding
lines to use the bits() function which removes the need to manually
mask or shift values. That makes it less likely for there to be a
mistake, and also makes it more obvious which bits are being accessed.
Change-Id: I692214f898e90dc7d5de460d1da2ef6aefda4fb8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25224
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
By using braced initializer lists and dropping the default
unimplementedFunc implementation function, the SyscallDesc tables
become a lot less crowded, and it's now very obvious which syscalls
are implemented just by quickly visually scanning the table.
This will also make it a lot easier to change the underlying type
stored in the table without having to adjust all of the instances
within them.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-187
Change-Id: I7821de74812e1c02ca4550fc9c46cc2188cf1bd0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23189
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
+ ArmISA.py: Enabling the feature adding QARMA algorithm as default.
+ faults.cc/faults.hh: Add PACTrapFault
+ includes/insts.isa: Adding new isa files.
+ aarch64.isa: Add decode part for PAC instructions
+ pauth.isa: Isa for PAC instructions
+ misc64.isa: PAC instructions templates
+ miscregs.cc/hh/types: New Registers for PAC Key low/high.
+ types.hh: Modification of system registers that were incomplete
for ARMv8
+ utility.hh: Add isSecureEL2 enabled. The function is there but will
always return false for now.
+ pauth_helpers.hh/cc: Implementation of auxiliar functions and derivates.
+ qarma.hh/cc: This functions follow ARMv8 reference pseudo code
implementing QARMA block cipher algorithms.
Change-Id: I3095a1279204206d9a816a4fb7fc176c18f9680b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25024
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Because the fast models (or at least the one we've looked at) give
access to the integer registers mostly based on the current view of
those registers, it does its own flattening and prevents accessing most
of the raw storage locations without this extra level of mapping. To
store to the flattened locations, we need to unflatten the indexes and
in one case shift the mode so that we get the right values.
Some registers which have irrelevant values for fast model (the "PC"
which is actually diverted elsewhere, the zero register, microcode
registers, and the "dummy" register), and those are left out of the
mapping so that they return 0 and blow up gem5 when someone attempts to
set them.
Change-Id: Ia2d315d5ca4c8a65b17ad52beff3a366ca8b3d46
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23791
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Chun-Chen TK Hsu <chunchenhsu@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These don't have anything in them at the moment since making some ISA
methods virtual and not inlined will likely add overhead, specifically
the ones for flattening registers. Some code may need to be rearranged
to minimize that overhead before the ISA objects can be truly put
behind a generic interface.
Change-Id: Ie36a771e977535a7996fdff701ce202bb95c8c58
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25007
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
