No description
Find a file
Brandon Potter a5802c823f syscall_emul: [patch 13/22] add system call retry capability
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.
2015-07-20 09:15:21 -05:00
build_opts riscv: [Patch 5/5] Added missing support for timing CPU models 2016-11-30 17:10:28 -05:00
configs arm,config: Add dist-gem5 support to the big.LITTLE(tm) config 2017-02-14 15:36:15 -06:00
ext misc: Update #!env calls for python to explicit version 2017-02-10 10:00:18 -05:00
src syscall_emul: [patch 13/22] add system call retry capability 2015-07-20 09:15:21 -05:00
system arm, config: Add an example ARM big.LITTLE(tm) configuration script 2016-07-21 17:19:16 +01:00
tests stats: Get all stats updated to reflect current behaviour 2017-02-19 05:30:32 -05:00
util sim: allow forward dependencies in checkpoint upgraders 2017-02-14 15:09:18 -06:00
.gitignore misc: Add dtb files to the ignore list for git and mercurial 2017-02-21 14:14:44 +00:00
.hgignore misc: Add dtb files to the ignore list for git and mercurial 2017-02-21 14:14:44 +00:00
.hgtags Added tag stable_2015_09_03 for changeset 60eb3fef9c2d 2015-09-03 15:38:46 -05:00
COPYING mem: Add memory footprint probe 2017-01-27 14:58:15 -06:00
LICENSE copyright: Add code for finding all copyright blocks and create a COPYING file 2011-06-02 17:36:07 -07:00
README misc: README direct to website for dependencies 2014-08-26 10:12:04 -04:00
SConstruct scons: make build better on FreeBSD 2017-02-09 19:00:00 -05:00

This is the gem5 simulator.

The main website can be found at http://www.gem5.org

A good starting point is http://www.gem5.org/Introduction, and for
more information about building the simulator and getting started
please see http://www.gem5.org/Documentation and
http://www.gem5.org/Tutorials.

To build gem5, you will need the following software: g++ or clang,
Python (gem5 links in the Python interpreter), SCons, SWIG, zlib, m4,
and lastly protobuf if you want trace capture and playback
support. Please see http://www.gem5.org/Dependencies for more details
concerning the minimum versions of the aforementioned tools.

Once you have all dependencies resolved, type 'scons
build/<ARCH>/gem5.opt' where ARCH is one of ALPHA, ARM, NULL, MIPS,
POWER, SPARC, or X86. This will build an optimized version of the gem5
binary (gem5.opt) for the the specified architecture. See
http://www.gem5.org/Build_System for more details and options.

With the simulator built, have a look at
http://www.gem5.org/Running_gem5 for more information on how to use
gem5.

The basic source release includes these subdirectories:
   - configs: example simulation configuration scripts
   - ext: less-common external packages needed to build gem5
   - src: source code of the gem5 simulator
   - system: source for some optional system software for simulated systems
   - tests: regression tests
   - util: useful utility programs and files

To run full-system simulations, you will need compiled system firmware
(console and PALcode for Alpha), kernel binaries and one or more disk
images. Please see the gem5 download page for these items at
http://www.gem5.org/Download

If you have questions, please send mail to gem5-users@gem5.org

Enjoy using gem5 and please share your modifications and extensions.