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>
Implementation of a generic frequency-based sampling
compressor. The compressor goes through a sampling stage,
where no compression is done, and the values are simply
sampled for their frequencies. Then, after enough samples
have been taken, the compressor starts generating
compressed data.
Compression works by comparing chunks to the table of
most frequent values. In theory, a chunk that is present
in the frequency table has its value replaced by the
index of its respective entry in the table. In practice,
the value itself is stored because there is no straight-
forward way to acquire an index from an entry.
Finally, the index can be encoded so that the values
with highest frequency have smaller codeword representation.
Its Huffman coupling can be used similar to the approach
taken in "SC 2 : A Statistical Compression Cache Scheme".
Change-Id: Iae0ebda08e8c08f3b62930fd0fb7e818fd0d141f
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37335
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.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 a gem5 op is triggered using a KVM MMIO exit event, the PC has
already been advanced beyond the offending instruction. Normally when
a system call or gem5 op is triggered, the PC has not advanced because
the instruction hasn't actually finished executing. This means that if
a gem5 op, and by extension a system call in SE mode, want to advance
the PC to the instruction after the gem5 op, they have to check whether
they were triggered from KVM.
To avoid having to special case these sorts of situations (currently
only in the clone system call), we can have the code which dispatches to
gem5 ops from KVM adjust the next PC so that it points to what the
current PC is. That way the PC can be advanced unconditionally, and will
point to the instruction after the one that triggered the call.
To be fully consistent, we would also need to adjust the current PC.
That would be non-trivial since we'd have to figure out where the
current instruction started, and that may not even be possible to
unambiguously determine given x86's instruction structure. Then we would
also need to restore the original PC to avoid confusing KVM.
Change-Id: I9ef90b2df8e27334dedc25c59eb45757f7220eea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38486
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These pseudo insts are less useful outside of full system, but they
should all still work. Removing this check makes it possible to, for
instance, test them in syscall emulation mode, and removes another
difference between the two styles of simulation.
Change-Id: Ia7d29bfc6f7c5c236045d151930fc171a6966799
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38485
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Input ports can specify a custom handler that is called
on resource stalls. The handler should return 'true' to
indicate the stall was handled and new messages from that
queue can be processed on that cycle. When it returns
'false' or no handler is defined, a resource stall is
generated.
Handlers are defined using the 'rsc_stall_handler' (for
resource stalls) and the 'prot_stall_handler' (for
protocol stalls) parameters. For example:
in_port(mandatory_in, RubyRequest, mandatoryQueue,
rsc_stall_handler=mandatory_in_stall_handler) {
...
}
bool mandatory_in_stall_handler() {
// Do something here to handle the stall !
return true;
// or return false if we don't want to do anything
}
Note: this patch required a change to the generate()
functions interface in the SLICC compiler, so we
could propagate a reference to the in_port to the
appropriate generate() functions. The updated interface
allows passing and forwarding of keyword arguments.
Change-Id: I3481d130d5eb411e6760a54d098d3da5de511c86
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31265
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Added functions for connecting the sequencer and cpu ports.
Using these functions instead of wiring up the ports directly allow
protocols to provide specialized sequencer implementations. For
instance, connecting the cpu icache_port and dcache_port to
different sequencer ports or to different sequencers.
A follow-up patch will update the configurations to use these
functions.
Change-Id: I2d8db8bbfb05c731c0e549f482a9ab93f341474b
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31417
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@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>
exp_cnt (expInstsIssued in the code) is used in the waitcnt instruction
to track that data has been read out of VGPRs in previous global
memory instructions, making it safe to overwrite the VGPRs used in said
global memory instructions.
Previously, exp_cnt wasn't being tracked at all, which lead to the
waitcnt finishing immediately, leading to the memory instruction's VPGRs
getting overwritten by subsequent instructions, causing errors.
This patch makes it so waitcnts waiting on exp_cnt will wait for MUBUF
buffer store instructions to read their VGPRs before completing
Change-Id: Idd2b59511bc086cf316217da27b7a228272b0b0f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37555
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The existing device tree generation method would use the default
frequency as both the min and max frequency when setting up the OSC
device tree nodes. This would sort of work, except it seems that if
the kernel needed to adjust a frequency, it would fail to do so since
it would assume the new frequency was out of range.
Since the existing property is used to set the initial frequency of
those clocks, and because the default, min and max frequencies are all
mostly independent variables (other than obvious ordering restrictions),
two new properties were added, min_freq and max_freq, which are only
there to fill in the frequency range property in the device tree. If
they aren't set, then the device tree generation method falls back to
the old way of using the default frequency as both min and max.
Change-Id: Ie907bd673f8bcb149e69e45c5b486863149b8a68
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37935
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Since this class has a custom destructor ~ProbeListener(), it should
also generally have the 4 other methods defined, otherwise calling
those methods lead to subtle failures.
In this specific case, the ProbeManager *const manager; field stores a
pointer back to the ProbeListener object at:
ProbeListener::ProbeListener {
manager->addListener(name, *this);
which gets unregistered by the destructor:
ProbeListener::~ProbeListener()
manager->removeListener(name, *this);
and because the default copy does not re-register anything, it leads to
unregistration.
Therefore, a copy constructor would need the manager to support multiple
identical listeners, or at least refcount them, which would be overkill.
The two move operations would be more feasible, as we could make them
unregister the old ProbeListener address and then re-register the new one,
but that is not very efficient, so we just delete them as well.
A consequence of not implementing the move methods is that it is
impossible to store ProbeListener inside an std::vector. since objects
inside std::vector may need to be moved in memory when the vector resizes,
and therefore need to be movable. The alternative is to use an std::vector
of std::unique_ptr instead.
Change-Id: I8dc0157665391f86e2ca81d144bc6a42e9312d6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37977
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.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>
In clang, the following error was given:
```
In file included from build/X86/sim/eventq.hh:51:
build/X86/sim/serialize.hh:533:19: error: 'ScopedCheckpointSection' is a protected member of 'Serializable'
Serializable::ScopedCheckpointSection sec(os, sectionName);
^
build/X86/sim/serialize.hh:175:11: note: declared protected here
class ScopedCheckpointSection {
^
```
The use, at line 533, was introduced in this commit:
https://gem5-review.googlesource.com/c/public/gem5/+/36135
This can be fixed by making ScopedCheckpointSection public.
Change-Id: Ib6ffba18d5e8c37980d4febb548f2405cb45ce8c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37915
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.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>
The SmartDict, used by buildEnv, has been added long time ago for
the following reasons: (checking its documentation)
---
The SmartDict class fixes a couple of issues with using the content
of os.environ or similar dicts of strings as Python variables:
1) Undefined variables should return False rather than raising KeyError.
2) String values of 'False', '0', etc., should evaluate to False
(not just the empty string).
---
These are valid reasons, but I believe they should be addressed in
a more standardized way by using a common dictionary.
1) We should simply rely on dict.get
if buildEnv.get('KEY', False/None):
2) We should discourage the use of stringified False or 0.
If we are using a dictionary, can't we just pass those values as
booleans?
The SmartDict is basically converting every value into a
string ("Variable") at every access (__getitem__)
The Variable is a string + some "basic" conversion methods
What is the problem of passing every dict value as a string?
The problem is the ambiguity on the boolean conversion.
If a variable is modelling a boolean, we can return true if
the value is 'yes', 'true'... and false if the value is
'no', 'false' etc. We should raise an exception if it is
something different, like a typo (e.g.) 'Fasle'.
But if the variable is not modelling a boolean, we don't know
how to handle that. How should we convert 'mystring' ?
If we decide to treat 'mystring' as True (which is basically
what a str.__bool__ would return) we will break typoes detection,
as 'Fasle' will now be converted to True, rather than raising
an exception.
Change-Id: I960fbfb1ec0f703e1e372dd752ee75f00632acac
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37775
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
