Take advantage of string comparisons when looking up what to do with a
given key.
Convert the key_str[12] registers from little endian to host endian.
This matches a corresponding change in the m5 utility to pack the
registers in little endian order, regardless of what the actual guest
endianness is.
Absorb the initparam_keys.hh header into sim/pseudo_inst.cc, and convert
its constants to c++ strings. The constants defined in it might be
useful to guest code calling into the m5 ops, but not for gem5 itself.
By merging them into the .cc file, we also don't have to do any tricks to
try to avoid them having multiple definitions.
Change-Id: I3a450ad7f9c4dca25f79c7835d7f9c167c02ae98
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27230
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
This change removes the responsibility for checking the number of
arguments and handing the default of no string back into init_param and
out of the function which packs strings into registers. It also renames
the function to more closely match its purpose, and rewrites it to be a
bit simpler and (IMHO) easier to follow.
Importantly, rather than doing a hand implemented strcpy which would
follow the endianness of the target/simulated platform, this change
makes this function pack the registers explicitly in little endian byte
order. This way on the consuming end in gem5, the initParam function
doesn't have to care what the guest endianness is, it can just translate
them from little endian to whatever the host endianness is (very likely
also little endian).
Change-Id: Ie9f79ecb8d4584c6e47a2793a31ccaa8c7c15986
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27229
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If the first register is all zeroes, it doesn't really matter what the
other register is. If the first register has the entire string, we still
don't care what the other register has in it. There's no reason to
complicate the code with these extra checks.
Change-Id: I22ad521b9ace915ccb75f15934fc6b3d650d5293
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27228
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
This command did not use any m5 ops, does the same thing as the
"taskset" command under Linux:
https://linux.die.net/man/1/taskset
and might even have introduced a build error if compiled for any other
OS since that would have left a trailing comma in the mainfuncs array.
While the last problem would be easy to correct, this is not related to
the purpose of this utility (giving access to m5 ops), and is redundant
with an existing standard utility provided with Linux.
Change-Id: Ie72b9310f5e6264f6035013f47ebe74a27464abb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27226
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Because I don't have a canonical toolchain to set SPARC's defaults to,
it will by default build for Linux instead of Solaris like it used to.
This will make it hard to test, but without a compiler there's not much
I can do.
This also coincidentally brings the SPARC version more in line with the
other variants which all target Linux.
Change-Id: Ie19217e988782da124306160920f40ef168840e4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27219
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
SVE half-precision floating-point instructions support only IEEE
754-2008 half-precision format and ignore the value of the FPCR.AHP bit,
behaving as if it has an Effective value of 0.
This patch is addressing this by masking the FPSCR.AHB bit before
passing it to fplib.
Change-Id: I1432fc3f7fefb81445fe042ae7d681f5cec40e64
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28108
Tested-by: kokoro <noreply+kokoro@google.com>
When compiling static objects, disable pie with the -no-pie linker flag.
This is necessary for x86, and doesn't seem to hurt anything for the
other variants.
When compiling shared objects, particularly the assembly files which
can't rely on the compiler to generate position independent code, define
M5OP_PIC so that the assembly code can configure itself correctly.
Change-Id: I80d1ea7a7704666027e74228036af5e0e4b9eac2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27218
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
As we are now going to maintain different bundles of resources for each
gem5 release, the resources have been archived to
http://dist.gem5.org/dist/current for gem5 19. The development branch
will use http://dist.gem5.org/dist/develop going forward. New releases
will follow the format http://dist.gem5.org/dist/{VERSION}.
This patch makes the resources url a command-line parameter, set to the
"correct" url by default. This will be updated to the correct, archived,
version subdirectory upon release of a new gem5 version. E.g.:
http://dist.gem5.org/dist/v20 for the gem5 20 release.
Some Make files have been cleaned up to no longer fetch and push to
remote locations. As gem5-resources is implemented, sources will be
moved to the gem5-resources resository and compiled binaries, etc.
pulled from our Google Cloud bucket from the tests themselves.
Change-Id: Ia16c496be3a60283ecc431ffaa5b059e1932b526
Issue-on: https://gem5.atlassian.net/browse/GEM5-431
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27987
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 Patch will fix the alignment problem that appears sometimes
when we try to create a view of 128 bits over the VecRegContainer
object.
That container is initially created as std::array<uint8_t, SIZE>, so
there is no obligation to be aligned to 16 bytes. This patches forces
all containers to be aligned to 16 bytes.
The problem has been observed in the Jira Issue:
https://gem5.atlassian.net/browse/GEM5-320
Change-Id: Id9fdd427bd7a4dc904edd519f31cc29c5b29c5e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27968
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch addresses multiple cases:
- When a controller has read/write permissions while others have read
only permissions, the one with r/w permissions performs the read as
the others may have stale data
- When controllers only have lines with stale or busy access permissions,
a valid copy of the line may be in a message in transit in the network
or in a message buffer (not seen by the controller yet). In this case,
we forward the functional request accordingly.
- Sequencer messages should not accept functional reads
- Functional writes also update the packet data on the sequencer
outstanding request lists and the cpu-side response queue.
Change-Id: I6b0656f1a2b81d41bdcf6c783dfa522a77393981
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22022
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: John Alsop <johnathan.alsop@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The components in base/loader were moved into a namespace called
Loader. This will make it easier to add loader components with fairly
short natural names which don't invite name collisions.
gem5 should use namespaces more in general for that reason and to make
it easier to write independent components without having to worry about
name collisions being added in the future.
Unfortunately this namespace has the same name as a class used to load
an object file into a process object. These names can be disambiguated
because the Process loader is inside the Process scope and the Loader
namespace is at global scope, but it's still confusing to read.
Fortunately, this shouldn't last for very long since the responsibility
for loading Processes is going to move to a fake OS object which will
expect to load a particular type of Process, for instance, fake 64 bit
x86 linux will load either 32 or 64 bit x86 processes.
That means that the capability to feed any binary that matches the
current build into gem5 and have gem5 figure out what to do with it
will likely be going away in the future. That's likely for the best,
since it will force users to be more explicit about what they're trying
to do, ie what OS they want to try to load a given binary, and also
will prevent loading two or more Processes which are for different OSes
to the same system, something that's possible today as far as I know
since there are no consistency checks.
Change-Id: Iea0012e98f39f5e20a7c351b78cdff9401f5e326
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24783
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is specialized per arch, and the Workload class is the only thing
actually using it. It doesn't make any sense to dispatch those calls
over to the System object, especially since that was, in most cases,
the only reason an ISA specific system class even still existed.
After this change, only ARM still has an architecture specific System
class.
Change-Id: I81b6c4db14b612bff8840157cfc56393370095e2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24287
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This generalized Workload SimObject is not geared towards FS or SE
simulations, although currently it's only used in FS. This gets rid
of the ARM specific highestELIs64 property (from the workload, not the
system) and replaces it with a generic getArch.
The old globally accessible kernel symtab has been replaced with a
symtab accessor which takes a ThreadContext *. The parameter isn't used
for anything for now, but in cases where there might be multiple
symbol tables to choose from (kernel vs. current user space?) the
method will now be able to distinguish which to use. This also makes
it possible for the workload to manage its symbol table with whatever
policy makes sense for it.
That method returns a const SymbolTable * since most of the time the
symbol table doesn't need to be modified. In the one case where an
external entity needs to modify the table, two pseudo instructions,
the table to modify isn't necessarily the one that's currently active.
For instance, the pseudo instruction will likely execute in user space,
but might be intended to add a symbol to the kernel in case something
like a module was loaded.
To support that usage, the workload has a generic "insertSymbol" method
which will insert the symbol in the table that "makes sense". There is
a lot of ambiguity what that means, but it's no less ambiguous than
today where we're only saved by the fact that there is generally only
one active symbol table to worry about.
This change also introduces a KernelWorkload SimObject class which
inherits from Workload and adds in kernel related members for cases
where the kernel is specified in the config and loaded by gem5 itself.
That's the common case, but the base Workload class would be used
directly when, for instance, doing a baremetal simulation or if the
kernel is loaded by software within the simulation as is the case for
SPARC FS.
Because a given architecture specific workload class needs to inherit
from either Workload or KernelWorkload, this change removes the
ability to boot ARM without a kernel. This ability should be restored
in the future.
To make having or not having a kernel more flexible, the kernel
specific members of the KernelWorkload should be factored out into
their own object which can then be attached to a workload through a
(potentially unused) property rather than inheritance.
Change-Id: Idf72615260266d7b4478d20d4035ed5a1e7aa241
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24283
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Two python Enum parameter types had some very generic elements which
both include one named "none". When headers for both are included that
creates a conflict which breaks the build. Enums which such extremely
generic names need to be scoped so that they don't invite these sorts
of collisions.
This change converts them from Enum to ScopedEnum in python, and also
makes a few small changes to where they're used in c++ to match.
Issue-on: https://gem5.atlassian.net/browse/GEM5-447
Change-Id: Ibda6e6cfcd700a618f8c68d174f33ec1e178b9ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27950
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
A new Prefetcher namespace was added which holds the gem5 prefetchers
and means they don't all need a "Prefetcher" in their name. Unfortunately
that means that there is now both a Prefetcher namespace and a
Prefetcher class which conflict with each other.
This change tries to resolve the conflict with as little disruption as
possible by simply renaming the c++ ruby Pretcher class RubyPrefetcher,
leaving the python name alone so that configs aren't affected.
Issue-on: https://gem5.atlassian.net/browse/GEM5-447
Change-Id: I7afdf5dbc57dbf46d82552113c52f3a9207870f2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27949
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It is assumed that the semihosting configuration uses the semihosting
number which includes gem5's pseudo insts.
Given the complexity and likely limitted value of letting the user
arbitrarily configure fast model's semihosting, and the fact that that
semihosting implementation would compete with gem5's own, those
parameters should be removed from python and set purely within C++.
Also note that if this semihosting support is used, the System object
needs to have an ArmSemihosting object installed to handle the calls.
Change-Id: I8e1de7717c9784dc7873795acd0a06389ec527b1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25623
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The GuestABI used to call the system-calls infers the size of values
read from the registers based on the function signature of the system
call. For mmap this was causing offset to be truncated to a 32-bit
value. In the GPUComputeDriver mmap, the offset must be a 64-bit
value. This fixes a bug where the doorbell memory was not setup and
causing GPU applications to fail.
Change-Id: I75d9b32c0470d1907c68826ef81cf6cd46f60ea7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27367
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The main applications are to run baremetal programs and initramfs Linux
kernel.
Before this patch, disks() calls in makeArmSystem would throw:
IOError: Can't find file 'linux-aarch32-ael.img' on M5_PATH.
In order to achieve this, this commit also removes the default hardcoded
disk image basenames.
For example, before this commit, running without a --disk-image in X86
would automatically search for an image with basename x86root.img in
M5_PATH, which means we would either have to ignore any disk image error,
or else running without disk images would fail.
After this commit, you would have to pass --disk-image x86root.img to
achieve the old behaviour.
Change-Id: I0ae8c4b3b93d0074fd4fca0d5ed52181c50b6c04
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27867
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This simplifies the SPARC FS workload significantly, and removes
assumptions about what ROMs exist, where they go, etc. It removes
other components from the loop which don't have anything to contribute
as far as setting up the ROMs.
One side effect of this is that there isn't specialized support for
adding PC based events which would fire in the ROMs, but that was never
done and the files that were being used were flat binary blobs with no
symbols in the first place.
This also necessitates building a unified image which goes into the single
8MB ROM that is located at address 0xfff0000000. That is simply done
with the following commands:
dd if=/dev/zero of=t1000_rom.bin bs=1024 count=8192
dd if=reset_new.bin of=t1000_rom.bin
dd if=q_new.bin of=t1000_rom.bin bs=1024 seek=64
dd if=openboot_new.bin of=t1000_rom.bin bs=1024 seek=512
This results in an 8MB blob which can be loaded verbatim into the ROM.
Alternatively, and with some extra effort, an ELF file could be
constructed which had each of these components as segments, offset to the
right location in the ELF header. That would be slightly more work to set up,
but wouldn't waste space on regions of the image that are all zeroes.
Change-Id: Id4e08f4e047e7bd36a416c197a36be841eba4a15
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27268
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
