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>
This function is based off of vtophys in the full system case, and off
of the page table fill mechanism used in SE mode. It ignores what's
already in the TLB, and also ignores protection mechanisms.
This may need to be reworked in the future if, for instance, pages
still resident in the TLB but not in the page tables need to be
considered, but it should work at least for the time being.
Change-Id: If21701ca36a30805f4199312933a8afc91f20501
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26405
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
All over gem5 the params pointers are not deleted within the classes
that they were created for. Although this is a potential memory leak
as of now, it is probably safer to follow general convention so that
it can be fixed at once in the future.
Change-Id: If96f04058d51513fa8763610880e5524785ee9cf
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24249
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
All over gem5 the params pointers are not deleted within the classes
that they were created for. Although this is a potential memory leak
as of now, it is probably safer to follow general convention so that
it can be fixed at once in the future.
Change-Id: I74b662a8e635cdfb4dc1eae732dd114659fab2e9
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24246
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
My new computer has a dynamic linker which seems to use the pread64
system call, and since that gets pulled in when running tests, that
needs to be implemented for tests to pass on that machine, making it
possible to detect problems the failure might ohterwise mask.
This is only really necessary for 64 bit linux, but while I'm here I
hooked it up for 32 bit linux as well. I also added pwrite64 for 32 bit
linux since that was only enabled for 64 bit.
Change-Id: I8d2061d30e98a1581c5e30b522b6ba12aea20ecd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26604
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Python 3 uses the concepts of two different types:
text and binary strings.
Those cannot be implicilty combined (as it was happening in python2) and
in order to be used together one of them must be converted to the other
type:
* Text can be encoded into Bytes via the encode() method
* Bytes can be decoded to Text using the decode() method
By default encode/decode will assume UTF-8 format
JIRA: https://gem5.atlassian.net/browse/GEM5-345
Change-Id: I1bdf7db17b49cc109239fd5f44791769370853f8
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26250
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
* dict methods dict.keys(), dict.items() and dict.values()
return "views" instead of lists
* The dict.iterkeys(), dict.iteritems() and dict.itervalues()
methods are no longer supported.
* map() and filter() return iterators.
* range() now behaves like xrange() used to behave, except it works with
values of arbitrary size. The latter no longer exists.
* zip() now returns an iterator.
Change-Id: Id480018239db88d7f5d60588c93719056de4a0c0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26248
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In case a workload is run with no bootloader we still want to be able
to provide the simulation with the correct arch version.
Without this patch every baremetal simulation will default to AArch64, which
is the default value of ArmFsWorkload.
Change-Id: I0f766167d8983cafc1fd30d054862339eb21f73f
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26606
Reviewed-by: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
