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>
This is another fix for the AArch32-AArch64 interprocessing issue
introduced in
3d15150d cpu, arch, arch-arm: Wire unused VecElem code in the O3 model.
Register mapping between AArch32 and AArch64 is explicitly defined in
ARMv8 manual. This allows software to read registers right after a state
switch without writing them first, and it is indeed common for software
to save registers to memory first before using them.
In gem5's implementation of vector mode switching, however, vectors may
not be marked as ready right after a state switch. Software reads toward
vectors at this time will stall O3CPU forever. This patch fixes this by
marking all mapped vectors (or vector elements, depending on AArch32 or
AArch64) as ready right after switching vector mode.
Change-Id: I609552c543dad8da66939c0a3079d73d48e92163
Signed-off-by: Hsuan Hsu <hsuan.hsu@mediatek.com>
Signed-off-by: Howard Wang <Howard.Wang@mediatek.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26203
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Fix MOESI_hammer checkpoint hanging.
The function markRemoved() should be called before hitCallback(),
not after it. The reason is that hitCallback() checks if draining is
complete based on the value of "m_outstanding_count". And since
markRemoved() is responsible for decrementing "m_outstanding_count",
hitCallback() does not see that there are no outstanding requests.
Reported by: Timothy Hayes
Jira: https://gem5.atlassian.net/browse/GEM5-331
Change-Id: I14c34be79843b172ae994ab1792fe4ce6cf5cf6e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25683
Reviewed-by: Timothy Hayes <timothy.hayes@arm.com>
Reviewed-by: John Alsop <johnathan.alsop@amd.com>
Maintainer: Bradford Beckmann <brad.beckmann@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
scons maintains an environment (in the shell sense) in the ENV
construction variable for use when running external programs. When we
run the "marshal" program which gathers up python objects to embed in
the gem5 binary, it's run by subprocess instead of through scons, and it
uses its own environment inherited from the host system.
Instead, this change makes the subprocess function use the scons
environment when calling "marshal". This ensures the environment is
consistent between this command and other commands scons runs.
This is usually not very important, but some tools like asan take
options set through the environment, and they may need to be adjusted
sometimes.
Change-Id: I671b447657ed8fad45fac7393cc1c09073bf3d3a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27123
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
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>
This updates the syscalls for mmap, munmap, and mremap. The mmap
changes now create a virtual memory area through the MemState class
to allow for lazy allocation of mmapped regions. This provides
substantial performance boost for sparse usage of mmaps. The munmap
syscall is added to reclaim the virtual memory area reserved for the
mmapped region. The mremap syscall moves or resizes an mmapped region
and updates the corresponding virtual memory area region to keep the
page tables in sync.
Change-Id: Ide158e69cdff19bc81157e3e9826bcabc2a51140
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26863
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.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>
This patch extends the IntrControl to provided additional member
functions for (1) clearing all pending interrupts in a PE and (2)
checking for any pending interrupt in a PE. These are intended to
be used from interrupt management related peripherals.
Change-Id: I06b553872ed469e7449b872a0716865773ace154
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26809
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.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>
There are a few problems with this check.
1. Many ISAs support multiple page sizes.
2. Memories (particularly small ROMs) may not actually be in multiples
of the page size.
3. In a heterogenous environment, there won't be a single page size even
if each ISA picks a canonical page size.
4. Other than catching some egregious configuration mistakes, there's
nothing functionally wrong/different about a memory that isn't evenly
coverable in pages, especially in systems or configurations that
don't even use paging.
Change-Id: I3cd241657318d2e3fd5a1226cb54fdebbf172788
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26423
Maintainer: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.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>
With:
https://gem5-review.googlesource.com/c/public/gem5/+/26466
The ArmSystem reset address (_resetAddr) is always forced by the
workload:
_resetAddr = workload->entry
So there is no possibility to manually specify a reset address.
This was not the case before:
The resetAddr was forced only if auto_reset_addr was true or if there
was an associated bootloader to the kernel image. In that case even if
auto_reset_addr was false, the reset address was determined by the
bootloader entry.
This was also not ideal (but it was working)
This patch is cleaning all of this:
If you want to have automatic detection (recommended), you would need to
set auto_reset_addr (now turned to true by default). This will allow to
keep most fs script untouched. If you don't want to use automatic
detection, set auto_reset_addr to False and provide your own reset
address.
Change-Id: I5d7a55fd9060b9973c7d5b5542bd199950e1073e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26723
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
The attachment (port binding) of the SMMUv3 master and control
ports is independent of the connection of device masters to it.
This behaviour is now moved from SMMUv3::connect to
RealView::attachSmmu, as it is a responsibility of the Platform
designer.
This fixes crashes when connecting multiple device masters.
Change-Id: If1e8f55d51876fe761f881e3044ffec637c21b09
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26923
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Virtual memory areas are used to track regions of memory which may
change over the course of execution, such as heap, stack, and mmap. It
is a high-level mimicry of Linux' memory management. VMAs are intended
to be used to support lazy allocation of physical pages to valid VMAs
as the virtual addresses are touched. Lazy allocation increases speed
of simulation for SE mode processes which, for example, mmap large
files.
The VMAs can also be queried to generate a map of the process' memory
which is used in some libraries such as pthreads.
This changeset only adds APIs for virtual memory areas. These are used
in a subsequent changeset.
Change-Id: Ibbdce5be79a95e3231d2e1c9ee8f397b4503f0fb
Signed-off-by: Brandon Potter <Brandon.Potter@amd.com>
Signed-off-by: Michael LeBeane <Michael.Lebeane@amd.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/25365
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@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>
The only functional difference between them was that the SE one might
have optionally fixed up missing translations for demand paging.
This lets us get rid of some code recreating the proxy ports in
setProcessPtr since the SE translating port no longer keeps a copy of
the process object pointer.
Change-Id: Id97df1874f1de138ffd4f2dbb5846dda79d9e4ac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26550
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
translateFunctional might be used with unaligned addresses which should
be allowed in that context. Also, in SE mode, if the translation isn't
in the TLB itself, then it should be looked up in the SE mode fake page
tables and not in a page table resident in memory.
Change-Id: Ibb39685cfdcd4eb6cb8a0486a1de014a4e452518
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26831
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This function is no longer used anywhere in gem5.
Small helper functions which had been put alongside vtophys on ARM and
RISCV were also moved into src/arch/arm/remote_gdb.cc and
src/arch/power/pagetable.hh, the only places they were used.
Change-Id: Iba72f6c4b797a35a785a5bb781d602c943541fa7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26234
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
