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 method lets system call implementations return values into
ThreadContexts other than the one they were called from. That's useful
for, for instance, clone() which creates new ThreadContexts.
By making it a virtual function in the SyscallDesc, we can delegate the
actual implementation to the SyscallDescABI subclass which knows the
ABI and how to use it to set the return value.
Change-Id: I61c6e60e4c2a8863c885cd818e4ff053fc3312ee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23503
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabeblack@google.com>
The system calls had four parameters. One of the parameters
is ThreadContext and another is Process. The ThreadContext
holds the value of the current process so the Process parameter
is redundant since the system call functions already have
indirect access.
With the old API, it is possible to call into the functions with
the wrong supplied Process which could end up being a confusing
error.
This patch removes the redundancy by forcing access through the
ThreadContext field within each system call.
Change-Id: Ib43d3f65824f6d425260dfd9f67de1892b6e8b7c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/12299
Reviewed-by: Brandon Potter <Brandon.Potter@amd.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch adds a default value of unimplementedFunc to SyscallDesc's
constructor's second argument, which makes adding system call
placeholders to SE mode cleaner.
Change-Id: I3e7efb3a887cc52d16d2095d3dd2e2a96fb882fb
Reviewed-on: https://gem5-review.googlesource.com/5501
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Brandon Potter <Brandon.Potter@amd.com>
Modifies the clone system call and adds execve system call. Requires allowing
processes to steal thread contexts from other processes in the same system
object and the ability to detach pieces of process state (such as MemState)
to allow dynamic sharing.
This changeset adds functionality that allows system calls to retry without
affecting thread context state such as the program counter or register values
for the associated thread context (when system calls return with a retry
fault).
This functionality is needed to solve problems with blocking system calls
in multi-process or multi-threaded simulations where information is passed
between processes/threads. Blocking system calls can cause deadlock because
the simulator itself is single threaded. There is only a single thread
servicing the event queue which can cause deadlock if the thread hits a
blocking system call instruction.
To illustrate the problem, consider two processes using the producer/consumer
sharing model. The processes can use file descriptors and the read and write
calls to pass information to one another. If the consumer calls the blocking
read system call before the producer has produced anything, the call will
block the event queue (while executing the system call instruction) and
deadlock the simulation.
The solution implemented in this changeset is to recognize that the system
calls will block and then generate a special retry fault. The fault will
be sent back up through the function call chain until it is exposed to the
cpu model's pipeline where the fault becomes visible. The fault will trigger
the cpu model to replay the instruction at a future tick where the call has
a chance to succeed without actually going into a blocking state.
In subsequent patches, we recognize that a syscall will block by calling a
non-blocking poll (from inside the system call implementation) and checking
for events. When events show up during the poll, it signifies that the call
would not have blocked and the syscall is allowed to proceed (calling an
underlying host system call if necessary). If no events are returned from the
poll, we generate the fault and try the instruction for the thread context
at a distant tick. Note that retrying every tick is not efficient.
As an aside, the simulator has some multi-threading support for the event
queue, but it is not used by default and needs work. Even if the event queue
was completely multi-threaded, meaning that there is a hardware thread on
the host servicing a single simulator thread contexts with a 1:1 mapping
between them, it's still possible to run into deadlock due to the event queue
barriers on quantum boundaries. The solution of replaying at a later tick
is the simplest solution and solves the problem generally.
The EIOProcess class was removed recently and it was the only other class
which derived from Process. Since every Process invocation is also a
LiveProcess invocation, it makes sense to simplify the organization by
combining the fields from LiveProcess into Process.
The class was crammed into syscall_emul.hh which has tons of forward
declarations and template definitions. To clean it up a bit, moved the
class into separate files and commented the class with doxygen style
comments. Also, provided some encapsulation by adding some accessors and
a mutator.
The syscallreturn.hh file was renamed syscall_return.hh to make it consistent
with other similarly named files in the src/sim directory.
The DPRINTF_SYSCALL macro was moved into its own header file with the
include the Base and Verbose flags as well.
--HG--
rename : src/sim/syscallreturn.hh => src/sim/syscall_return.hh
