This simplifies the O3 CPU, and removes special cases around how vector
registers are handled. Now ARM is responsible for maintaining its
different register personalities internally.
Also, this re-establishes the invariant that registers are indexed as
complete, opaque entities with no internal structure, at least as far as
the CPU is concerned.
To make sure the KVM CPU sees the correct state, we need to sync over
the vector registers if we're in 32 bit mode when moving state to or
from gem5's ThreadContext.
Change-Id: I36416d609310ae0bc50c18809f5d9e19bfbb4d37
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49147
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The x86 KVM CPU had been in the cpu/kvm directory, while the arm CPU was
inconsistently in the arch/arm directory.
This change moves the x86 CPU to be in arch/x86, restoring consistency.
This location will make the KVM support more modular, by not having the
x86 CPU implementation right alongside the generic implementation.
Change-Id: Ia13151f843df8f8877bfef5ff620825877d3dffa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52085
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This translation generator is returned by the new version of the
TranslateFunctional method which translates a region rather than a
single address. That method is currently virtual with a default
implementation which is not overloaded, but the plan is for the other
MMUs to override that method and inject their own page size minimally.
In the future, the MMUTranslationGen class and the implementations in
the MMUs may be updated so that they can, for instance, handle varying
page sizes across a single translation.
Change-Id: I39479f0f0e8150fc6e3e1a7097a0c8bd8d22d4e0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50759
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The arch implies gem5 lib, and not the other way around. Or in other
words, if, for example, x86 is the ISA, the having the tag 'x86 isa'
would imply that that file also has the tag 'gem5 lib'. Having the tag
'gem5 lib' would not imply 'x86 isa'.
This worked out because when testing for a single tag, we were using
with_any_tags, and 'gem5 lib' would expand to 'gem5 lib' and 'x86 isa'.
Then we would match files which were non-specific and used 'gem5 lib',
or files which had more specifically used 'x86 isa' only. Files which
used, for instance, 'arm isa', would not meet either criteria of the
implied "or".
Change-Id: I301d1bbbbcac1594371584d4b0d5d291b7b77fc4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51827
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Otherwise, SCons may discover an include which is guarded with BUILD_GPU
(like GPUCoalescer in mem/ruby/profiler/Profiler.cc), but not understand
that BUILD_GPU is not true. It will then follow the includes and find
generated headers which it will then generate, specifically X86 headers
for X86TLB and X86Pagetable param structs.
If not using x86, for instance if building the NULL isa, it may not be
possible to generate those headers because those objects are not visible
to SCons.
Change-Id: I955d0ef6ffb146eeb99bb052d29abe835cac5d9a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51829
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When an object is a field in a union, it's the programmer's
resposibility to destroy it from the union's destructor. We can simply
neglect to do that and avoid having to use new to create the flags.
Also, we can define the flags as inline variables (a c++17 feature), and
then create a constexpr references to them. This lets us refer to debug
flags in constexpr objects, although we can't interact with them at, for
instance, construciton time or we'd lose our own constexpr-ness since
the actual object is not constexpr.
In c++20 we would hypothetically be able to use constexpr with new and
delete, but there may be additional restrictions that would make this
particular use impossible. Also this avoids leaking memory, which, even
though it's intentional, may confuse tools like valgrind.
Also, we need to ensure that all headers are included in some source
file so that they exist in the final executable, so that they show up in
the help, can be enabled/disabled, etc.
Change-Id: Ia43111d938e7af7140b1c17dd68135f426d0a1e9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49783
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jui-min Lee <fcrh@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We shouldn't print all TLB stats regardless of their value
For example there is no need to print the number of
read/write hits/misses/accesses in a instruction only TLB as
it will always inevitably be zero
With this patch we are flagging them as nozero, in order
to suppress their printing in the final stats file.
We are still printing them (regardless of their value) in the
unified TLB type
Change-Id: I54e57d856ceb451f6bacdd175a61768d030862aa
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51667
Tested-by: kokoro <noreply+kokoro@google.com>
We want to insist that the fast model libraries are the static versions
so they don't have to be found on non-system paths at run time, but we
don't need or want to do the same for system libraries which are from
standard paths on the host system.
Split the set of libraries fast model adds to the build into ones that
come from fast model itself, and ones it needs which should be
provided by the system. The ones from fast model itself should still
go through staticify, but the system libraries should be passed to the
compiler generically so it can pick which version it wants.
Change-Id: I222c94f8117143b86377150e686a4af669a994fe
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51627
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
0F 38 is the two bytes prefixes to decode a three-byte opcode.
To prevent errors, the two_bytes_opcode decoder will complain
if it tries to decode 38 as the opcode, because it is a prefix.
The decoder, will treat 38 as a prefix, preventing it to
end in the two_byte_opcode decoder.
However, using the VEX prefix is possible to reach this
forbidden state.
The set of bytes C4 01 01 38 00 will trigger the mentioned
M5InternalError.
The previous instruction is not valid, but it could be
decoded from an speculative path. In its place, a UD2
instructtion should be emitted if the VEX prefix is
present.
Change-Id: I6b7c4b3593dd8e6e8ac99aaf306b8feeb7784b56
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49990
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Move GpuTLB and TLBCoalescer to GCN3 as the TLB format is specific to
GCN3 and SE mode / APU simulation. Vega will have its own TLB,
coalescer, and walker suitable for a dGPU. This also adds a using alias
for the TLB translation state to reduce the number of references to
TheISA and X86ISA. X86 specific includes are also removed.
Change-Id: I34448bb4e5ddb9980b34a55bc717bbcea0e03db5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49847
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
