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>
For some segments, there are two base registers. One is the
architecturally visible base, and the other is the effective base used
when actually referencing memory relative to that segment. The process
initialization code was setting the architecturally visible base,
presumably because that's the value used by KVM, but was setting the
effective base to zero.
Change-Id: I06e079f24fa63f0051268437bf00c14578f62612
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38488
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When the result is returned to the caller from the pseudoInst dispatch
function, the default behavior is to not store that value using the
guestABI mechanism. In the x86 definition, I accidentally used this
version but then didn't store the result manually. The fix should simply
be to not return the result to the instruction definition and to let the
guestABI mechanism handle everything normally.
Change-Id: Ib69f266ad6314032622e5d8d69e9ff114c62657a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38195
Reviewed-by: Daniel Gerzhoy <daniel.gerzhoy@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This register is used since the Linux kernel 5.6 aarch64 boot.
This register indicates CPU capabilities in aarch32 mode, and it has the
same value as the aarch32 ID_ISAR6 miscregister, which is also added.
The capability values of those registers are analogous to those present in
aarch64 accessible ID_AA64ISAR0_EL1 and ID_AA64ISAR1_EL1, which refer to
aarch64 capabilities however, and were already implemented before this
commit.
The arm architecture document clarifies that reads to this system register
location before it had been defined should return 0, but we were faulting
instead:
> Prior to the introduction of the features described by this register,
this register was unnamed and reserved, RES0 from EL1, EL2, and EL3.
Change-Id: I70e99536dc98925e88233fd4c6887bbcdd5d87dc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30935
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Once all ISAs are converted, the base StaticInst class will be able to
drop its local arrays, and will no longer need to know what the global
maximum number of source or destination registers is for a given
instruction.
Most of the convertion was very simple and just involved adding tags to
declare and install the register arrays in all the class definitions.
Since SPARC has a relatively simple ISA definition, there weren't many
places that needed to be updated.
The exception was the BlockMem template, which was declaring the microop
classes within the body of the macroop. That was ok when those
declarations didn't need anything other than the name of their parent,
but now they also need to know how big to declare their arrays based on
their actual implementation.
To facilitate that, and to significantly streamline the definition of
the macroop class, the microop class definitions were moved to their own
template, and only the declaration was left in the parent class.
Change-Id: I09e6b1d1041c6a0aeaee63ce5f9a18cf482b6203
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36879
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This will prevent checkpoints from breaking on every miscreg addition.
Before this commit, miscregs were stored as an array:
[system.cpu.isa]
miscRegs=965 0 0 0 0 0 0 0 0 0 0 0 17895697 ...
and after this commit they are stored as a map:
[system.cpu.isa]
[system.cpu.isa.miscRegs]
cpsr=965
spsr=0
spsr_fiq=0
spsr_irq=0
spsr_svc=0
spsr_mon=0
spsr_abt=0
spsr_hyp=0
spsr_und=0
elr_hyp=0
fpsid=0
fpscr=0
mvfr1=17895697
JIRA: https://gem5.atlassian.net/browse/GEM5-661
Change-Id: I49999c7206bd9ac1cfb81297d45c8117ff8ae675
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36116
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are two new strings, reg_idx_arr_decl which declares the source
and dest register index arrays, and set_reg_idx_arr which installs them
in the base class.
The set_reg_idx_arr code needs to implicitly figure out what type to use
based on the type of the "this" pointer. The name of the containing
class is not *necessarily* the same as class_name, since the generated
code can use that name, something based on that name, or whatever else
it wants. No other format string (other than class_name itself) uses the
class name internally, so we can't count on that working in existing ISA
definitions.
Change-Id: Id995a46896e71a2fcf3103c34a1e1e67e24f88f4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36878
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There were accessors for reading these indexes, but they were not
consistently used. This change makes them private to StaticInst, and
changes places that were accessing them directly to instead use the
accessors. New accessors are added for code generated by the ISA parser
and some ARM code to set the indexes without accessing them directly.
By forcing these values to be behind accessors, it will be much simpler
to change how those values are stored and retrieved.
Change-Id: Icca80023d7f89e29504fac6b194881f88aedeec2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36875
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Several TLB invalidation instructions rely on VMID matching. This is
only applicable is EL2 is implemented and enabled in the current state.
The code prior to this patch was making the now invalid assumption that
we shouldn't consider the VMID if we are doing a secure lookup. This is
because in the past if we were in secure mode we were sure EL2 was not
enabled.
This is fishy and not valid anymore anyway after the introduction of
secure EL2.
Change-Id: I9a1368f8ed19279ed3c4b2da9fcdf0db799bc514
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35242
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Modern libraries such as ROCm, MPI, and libnuma use files in Linux'
sysfs to determine the system topology such as number of CPUs, cache
size, cache associativity, etc. If Linux does not recognize the vendor
string returned by CPUID in x86 it will do a generic initialization
which does not include creating these files. In the case of ROCm
(specifically ROCt) this causes failures when getting device properties.
This can be solved by setting the vendor string to, for example,
AuthenticAMD (as qemu does) so that Linux will create the relevant sysfs
files. Unfortunately, simply changing the string in cpuid.cc to
AuthenticAMD causes simulation slowdown and may not be desirable to all
users. This change creates a parameter, defaulting to M5 Simulator as it
currently is, which can be set in python configuration files to change
the vendor string. Example of how to configure this is:
for i in range(len(self.cpus)):
for j in range(len(self.cpus[i].isa)):
self.cpus[i].isa[j].vendor_string = "AuthenticAMD"
Change-Id: I8de26d5a145867fa23518718a799dd96b5b9bffa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36156
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
