GPU MTYPE is currently set using a global config passed to the
PACoalescer. This patch enables MTYPE to be set by the shader on a
per-request bases. In real hardware, the MTYPE is extracted from a
GPUVM PTE during address translation. However, our current simulator
only models x86 page tables which do not have the appropriate bits for
GPU MTYPES. Rather than hacking non-x86 bits into our x86 page table
models, this patch instead keeps an interval tree of all pages that
request custom MTYPES in the driver itself. This is currently
only used to map host pages to the GPU as uncacheable, but is easily
extensible to other MTYPES.
Change-Id: I7daab0ffae42084b9131a67c85cd0aa4bbbfc8d6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42216
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
dev/ has unit tests, but they are not run when
using the NULL ISA. The currently existing tests
are not ISA-specific, so the tests were set to
be run at an ARM environment.
As of now this is enough, but when ISA-specific
tests from ISAs other than ARM are added one will
need to change to cover them too.
Change-Id: I18df0141d415286325463afa759459b04ac8a92f
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44367
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There was a merge error caused by new options being added to this script
while all scripts were being converted from optparse. This fixes the
error.
This also removes the mostly unused setOption / getOption as you can
directly assign a value to an argument after parsing
Change-Id: Ic8aaa0728a43936cd4c6e1ed590e01ba5f0fbf5b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44785
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
gcc provides __uint128_t and __int128_t types which represent 128 bit
wide unsigned and signed integers, respectively. We can detect that
extension and use it to perform wide multiplication which takes
advantage of the built in single multiply instruction on x86 hardware
without having to compute the value manually with 64 bit variables.
Since both gcc and clang should support this extension and the manual
version may not be exercised normally, this change also extends the
gtest for intmath so that it will explicitly run the manual versions of
these functions. On systems with the extension both versions will be
tested, and on other systems the manual version will be harmlessly
tested twice.
Change-Id: I32640679396584cd43bc91a3f7e649c6e6f94afa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42359
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
These implementations are from the x86 multiply microops. When
multipying two integers of a certain width together, these functions
will produce two values of the same size which hold the upper and lower
part of the multiplication result.
The version which works for 32 bit values and smaller just takes
advantage of 64 bit multiplication using standard types. The 64 bit
version needs to do more work since there isn't a built in standard
facility for doing those sorts of multiplications.
Change-Id: If7b3d3aa174dd13aae6f383772cbc5291181de5d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42358
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This says *which* thread context you're replacing. Right now it's
implied that you're replacing the only thread context, but once we
support having multiple threads in the same GDB endpoint, that will no
longer be implied.
Change-Id: I5a789d12bbe195e019d5ccd8a005b5a6f16b9299
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44610
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
These instructions go through a lot of effort to extract bitfields, sign
extend them, and cast things to an appropriate type/size.
Instead, we can define a BitUnion which has the appropriate ranges of
bits predefined, and take advantage of the fact that every bitfield
returns its value as either a uint64_t if it's unsigned, or an int64_t
if it's signed.
Also, stop setting resTemp if it's not going to be used to set condition
codes or used as an intermediate in calculating the destination
registers.
Change-Id: Ia511aa74c823fad48080de4fbf77791c0cb3309d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42387
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Having const and non const reference accessors for the RegId index are
basically the same thing as just making the index value public but with
more complexity. Stop allowing updates through the accessor, and
simplify/fix the one location that was using that.
Also, there is no good reason to return an integer value by const
reference instead of returning it by value, since the value being passed
around (a pointer) is the same size, and just makes the value harder to
access.
Change-Id: I377ffc5878ef9bffa2ac53626a87c019a585ab1a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42684
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The isZeroReg() helper checked if the register was both an integer
register, and if it equaled TheISA::ZeroReg. This bakes in both the
assumption that any zero registers are integer (and that integer
registers are a thing), and also internalizes the plumbing which selects
what index is the zero register.
This change eliminates the isZeroReg helper and moves the logic inside
it into where it was called. In most cases, it was actually not
necessary to check if the register was integer since that was already
implied by context. This also brings the TheISA::ZeroReg constant out,
where it can be replaced by values plumbed in more generally than a
fixed, ISA specific constant.
Change-Id: I651762b6eb01fea83ec0b0076e8be9bf24b5b0da
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42683
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When a segfault happens in the guest, report a SEGV trap to GDB (if
there is one attached) instead of bailing out immediately.
The obvious use-case for this, is the ability to debug guest crashes
in GDB in the standard manner.
The less-trivial use-case is for development of software in an
incomplete software stack (cf. Aarno-Engblom's "Virtual Platforms"
pp.105 et seq.) One particular example is Ingalls-Miranda simulation of
JIT compilers, where the VM's address space may be split between the
simulated and the real machine: in this case, GDB traps facilitate the
transparent illusion of an unbroken address space.
Change-Id: I9072ed5f6474e05e9a99dc42ae5754be28121355
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44685
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The --restore_simpoint_checkpoint option is a boolean;
however if no default value is supplied, optparse sets the
default value to None
This is not valid for argparse. Argparse recognizes the store_true
action and it is automatically treating the option as a boolean,
hence providing a default=False instead of default=None
Change-Id: I6b09edf6911be71a06001730be1232a1b5c8482c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44765
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The code which registers thread contexts originally returned the ID that
it had chosen, and let the CPU actually set the ID in the object itself.
That opened a window where calling contextId() on the ThreadContext
would return the wrong answer.
Instead, we can just set the ID immediately after it's decided. This
also localizes that logic and removes plumbing for the ID between that
decision and where it's actually applied.
Change-Id: I31ad84c3f9bf6f5b6f72457ca640ea929b24f6a0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44615
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
The existing send method takes a const char *, but frequently the class
wants to use it to send a std::string, also frequently after generating
that string with csprintf. Rather than force each call sight to add a
.c_str() and call csprintf, this change adds helpers which will accept a
std::string and call c_str for you, or accept a format const char * and
arguments and call csprintf for you (and then call .c_str() on the
result).
Change-Id: Ifcef5e09f6469322c6040374209972528c80fb25
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44607
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Several sext<> calls had an off by one sign bit index, which is really
the size of the number which is being sign extended. Also, two calls in
arch/sparc/tlb.cc seemed to assume that the argument to that function
was modified in place, where really the new value is returned
separately. Move the call to sext so its return value is used and not
thrown away.
Change-Id: I86cb81ad243558e1a0d33def7f3eebe6973d6800
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42603
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The remote GDB protocol encode thread IDs as positive integers, where 0
is a special value which indicates "pick any thread", and -1 is a
special value which indicates all threads.
The previous implementation would look like it worked handling the
special value -1 (for instance) because it see the '-' of "-1", stop
looking for digits, and return the default value 0.
This new implementation handles -1 as a special case, and will report an
error if no digits were found otherwise.
Also this change adds an encodeThreadId method to convert a ContextID
into a GDB thread ID by adding one to avoid the special value 0.
Change-Id: Iec54fbd9563d20a56011f48d50d69111ed1467b8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44606
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
It was quite incovenient to declare tags. tags either
had to be added to the Source declaration of included
files, or using (with_tag()) would need to be added
with all the indirect sub-tags. For example,
Assume:
- B.cc refers to symbols in A.cc
- C.cc refers to symbols in B.cc (i.e., it needs A transitively)
- D.cc refers to symbols in A.cc and C.cc (i.e., it needs B trans.)
So either their SConscript would be:
Source('A.cc', add_tags=['B', 'D'])
Source('B.cc', add_tags='B')
Source('C.cc', add_tags='C')
Source('D.cc', add_tags='D')
GTest('A.test', 'A.test.cc', 'a.cc')
GTest('B.test', 'B.test.cc', with_tag('B'))
GTest('C.test', 'C.test.cc', with_any_tags('B', 'C'))
GTest('D.test', 'D.test.cc', with_any_tags('B', 'C', 'D'))
or:
Source('A.cc', add_tags=['B', 'C', 'D'])
Source('B.cc', add_tags=['B', 'C', 'D'])
Source('C.cc', add_tags=['C', 'D'])
Source('D.cc', add_tags='D')
GTest('A.test', 'A.test.cc', 'a.cc')
GTest('B.test', 'B.test.cc', with_tag('B'))
GTest('C.test', 'C.test.cc', with_tag('C'))
GTest('D.test', 'D.test.cc', with_tag('D'))
This change makes it simpler. The tag should be added
only to the files directly included by the functionality
being tagged. Using the same example:
Source('A.cc', add_tags=['B', 'D'])
Source('B.cc', add_tags='B')
Source('C.cc', add_tags='C')
Source('D.cc', add_tags='D')
env.TagImplies('B', 'A')
env.TagImplies('C', 'B')
env.TagImplies('D', ['A', 'C'])
GTest('A.test', 'A.test.cc', 'a.cc')
GTest('B.test', 'B.test.cc', with_tag('B'))
GTest('C.test', 'C.test.cc', with_tag('C'))
GTest('D.test', 'D.test.cc', with_tag('D'))
This also means that when a file no longer refers to
symbols from other file, or when it starts refering to
symbols from another file, one only needs to change
the dependencies of the tag directly being modified,
not the tags that rely on (imply) them. That is, on
the previous example, if C stops refering to symbols
from B, then tags that imply C do not need to be
modified:
env.TagImplies('B','A')
env.TagImplies('D', ['A', 'C'])
Change-Id: I5be07b01864f8d5df83f59002dfd2f01c73d5e09
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/43587
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Instead, create a new tool called EnvDefaults. This tool now needs
to be explicitly listed in the set of tools available through an
Environment, but that's easy to do in on place (all environments should
stem from main). Hijacking default like we were doing was (as far as I
can tell) not how that tool was intended to be used, and doing things
this way is a bit less hacky.
Also, we can split more Builders, etc, out of SConstruct, and these will
need to attach to main in the same way. We're going to need a list of
tools when main is constructed one way or the other, so we might as well
follow the rules.
Change-Id: I392e1639cb69d373c64970dccf45258000498cc3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40965
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The nullStaticInstPtr was low overhead, but the nopStaticInstPtr needed
an actual StaticInst implementation it could point to, and that brought
with it some (minor) additional dependencies. Specifically, the
implementation of advancePC needs the definition of TheISA::PCState,
while all other signatures/impementations in StaticInst are already
passing around that type by reference or could be made to, reducing
dependencies further.
Change-Id: I9ac6a6e5a3106858ea1fc727648f61dc39738a59
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42968
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Despite the generic sounding name and sort of generic contents, the
BaseDynInst was actually tied to the O3 CPU. Having the two independent
moving pieces created complexity but provided no real benefit. This was
evidenced by the fact that no CPU other than O3 actually used that
class.
Change-Id: I4ea1d053e2e172ececdc3113b8d76d5ad7490fc7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42094
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We have seen cases where the primary CPU was not able to bootstrap the
secondary CPUs in multicore tests (dual). The Linux booting process
"quietly" gives up (no panic) and it completes the booting without
bringing up the seondary CPU(s). This makes the dual test useless as it
is supposed to test SMP setups.
By adding a MatchFileRegex verifier, we make sure we are able to catch
these cases, correctly raising an error if not all CPUs are available.
We do this by inspecting the kernel log for the following print:
"CPU1: Booted secondary processor"
There are probably more resilient alternatives to a regex based check,
but those require a less minimal rootfs (the current
m5_exit.squashfs.arm64 FS has a single /sbin/init binary executing a
simple m5 exit operation)
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: I37e0882967443449d5fedfe3963bd25528a030f8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44446
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
CfiMemory: This is modelling a flash memory adhering to the
Common Flash Interface (CFI):
JEDEC JESD68.01
JEDEC JEP137B
Intel Application Note 646
This is as of now a pure functional model of a flash controller: no
timing/power information has been encoded in it and it is therefore not
representive of a real device. Some voltage/timing values have
nevertheless been encoded in the CFI table. This is just a requirement
from the CFI specification: guest software might query those entries,
but they are not reflected in gem5 statistics.
The model is meant to be used to allow execution of flash drivers (e.g.
UEFI firmware storing EFI variables in non volatile memory)
JIRA: https://gem5.atlassian.net/browse/GEM5-913
Change-Id: Id99e331ac8237f3ecb69d618da0d7ca7b038cd1f
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41495
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This increases the width of the general-purpose registers
and some of the special purpose registers to 64 bits in
accordance with recent versions of the Power ISA. This
allows the registers to be used for both 32-bit and 64-bit
execution modes.
It should be noted that in 32-bit mode, the use of upper
word is dependent on the instruction being executed and in
some cases, this may be undefined.
Change-Id: I2a5865a66e4ceab45e42a833d425abdd6bd6bf55
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40881
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
New topology ripped from Fiji to support dGPU. A dGPU flag is added to
the config which is propogated to the driver. The emulated driver is
now able to properly deal with dGPU ioctls and mmaps. For now, dGPU
physical memory is allocated from the host, but this is easy to change
once we get a GPU memory controller up and running.
Change-Id: I594418482b12ec8fb2e4018d8d0371d56f4f51c8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42214
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
