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>
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>
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>
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>
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>
This is fixing switcheroo tests when using a PMU/GICv3. When you switch
cpus you usually instantiate multiple cpus at the beginning and you
switch them at runtime with the m5.switchCpus function.
Every cpu will have its own set of ThreadContexts/ISAs.
When you switch cpu/tc/isa, you need to update the tc/isa pointer
cached in the device model otherwise those will still reference
the switched out cpu.
Change-Id: I3aeee890286851189c3a8a4d378c83f32e973361
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27713
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Faults in the TLB ought to cause a page walk. Force that by removing
the fixup in X86 TLB.
This fixes rare race conditions where a timing page walk is
intercepted by a TLB miss which fixes up the fault resulting in
double calls to allocateMem in Process class.
Change-Id: Iaef4d636cd2997144d8bc5012cd7c2a0a97102e5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27507
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This is in the range of call numbers set aside for extensions. When
called, it will extract the function to use from the first argument
slot. Then it calls the pseudoInst dispatching function using an ABI
which drops the return value (which is handled by semihosting itself)
and which extracts arguments from the remaining slots in the param
structure.
This makes gem5 pseudo ops available on CPU models which support
semihosting but not instruction based or address based "magic"
operations, aka hypercalls. This includes the fast model CPUs.
Change-Id: Ic4817f2b1e6aad7784af77a1a494cf614d4d4c6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25950
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ARM's semihosting interface defines call numbers up to 0xff to be
for standardized use, and says that custom calls should go above this
number.
This new mechanism will let the caller decide whether it wants to
enable these extended calls, or if they should be ignored and only
standard calls should be recognized.
Change-Id: I34b01a4439c8a88242971ac486e34d810b054baf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25947
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Switch over to the new MemState API by specifying memory regions for
stack in each ISA, changing brkFunc to use MemState for heap memory,
and calling the MemState fixup in fixupStackFault (renamed to just
fixupFault).
Change-Id: Ie3559a68ce476daedf1a3f28b168a8fbc7face5e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25366
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Extend the MemState API to handle tracking dynamically sized memory
regions of a Process class which may be added, moved, removed, or
change in size during the course of simulation. This utilizes the
virtual memory areas (VMA) class to track individual regions and
provides a fixup method to handle physical page allocation in case of
a page fault. This allows for lazy allocation of the stack, heap, and
mmap regions of memory.
Change-Id: I3ef10657e5f8e8f0e328bdf0aa15a27b1dde39bf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25483
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Remove the ability to not have an implementation for a semihosting call
in 32 or 64 bit mode since that was not actually being used. It can be
reintroduced if needed in the future.
Turn the physProxy helper function into a static function which
maintains a single secure port proxy. That makes the proxy available
outside of the ArmSemihosting class itself.
Change-Id: Ie99e7d79c08c039384250fab0c98117554c93128
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25946
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>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Some compilers won't build ARM due to how guest ABI
has been implemented.
The error is: "left shift count >= width of type"
[-Werror=shift-count-overflow]
The error is triggered when there is a left shift > the variable size
(in bits); this leads to undefined behaviour.
This is a compile time vs run time problem; the code is technically
fine, but the compiler is not able to understand this.
For example in aapcs64:
struct Argument<Aapcs64, Integer, typename std::enable_if<
std::is_integral<Integer>::value>::type> : public Aapcs64ArgumentBase
{
[...]
if (sizeof(Integer) == 16 && state.ngrn + 1 <= state.MAX_GRN) {
Integer low = tc->readIntReg(state.ngrn++);
Integer high = tc->readIntReg(state.ngrn++);
high = high << 64;
return high | low;
}
}
Even if the sizeof operator will be evaluated at compile time,
the block will be executed at runtime: the block will still be part of
the code if Integer = uint32_t.
The compiler will then throw an error because we are left shifting an
uint32_t by 64 bits.
Error arising on:
Compiler: gcc/5.4.0
Distro: Ubuntu 16.04 LTS
Change-Id: Iaafe030b7262c5fb162afe7118ae592a1a759a58
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26990
Reviewed-by: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
gem5 will panic if it encounters a trap it doesn't know what to do with.
Newer versions of glibc, gcc, etc., use the getcontext trap in setjmp
during startup.
This change hooks up a function for both the getcontext and setcontext
traps. The getcontext one just warns that it isn't implemented. If the
context it creates is never used (likely) then that should be fine for
now. If we ever try to actually use a context with setcontext, then
something bad will almost certainly happen if it's not implemented, and
we panic.
Change-Id: Id6797ac6955249d299e975c9c30360920d380e60
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26825
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When handling a system call, external code would call Process::syscall
which would extract the syscall number, that would call the base
class' doSyscall method, that would call into the subclass' getDesc
to get the appropriate descriptor, and then doSyscall would check
that a syscall was found and call into it.
Instead, we can just make the SyscallDescTable optionally check for
missing syscalls (in case we want to check multiple tables), and
make syscall look up the appropriate descriptor and call it. The base
implementation of syscall would then do the only bit of doSyscall that
is no longer being handled, incrementing the numSyscalls stat.
Change-Id: If102c156830ed2997d177dc6937cc85dddadf3f9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24119
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Also add the syscall number into the SyscallDesc class.
The common table structure is basically just a map that extracts its
key value from the SyscallDesc class using a new num() accessor. By
using a map instead of an array (like RISCV was already doing), it's
easy to support gaps of arbitrary size and non-zero offsets of groups
of system calls without lots of filler or additional logic. This
simplified the ARM system call tables in particular which had a lot
of filler entries.
Also, both the 32 and 64 bit ARM syscall tables had entries for a
syscall at 123456 which was the "Angel SWI system call". This value
is actually the immediate constant passed to the SWI system call
instruction and is not interpreted as the system call number in linux.
This constant can be intercepted by hardware or a simulator to, for
instance, implement ARM semihosting.
Also, that constant in combination with the SWI instruction is only
used for semihosting in 32 bit ARM mode, not in 64 bit mode or in
thumb.
Since checking for that system call number was very likely a mistake
from misinterpreting how the semihosting calls work, this change
drops those checks.
Change-Id: I9b2a902d7326791449cf0e1b98e932dcadba54f7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24117
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This class read arguments using the arch specific getArgument function
and then presented the arguments as an array. The problem with that
approach is that it's not possible to tell where different arguments
are without knowing the types of previous arguments, and not all
arguments can be simply represented as a native sized integer.
This class has been phased out and is no longer needed.
Change-Id: Ibb4c529fe8c51fd0ae15ed3b6ea30543ad9c23e0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24115
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
