FireMarshal is still in alpha. You are encouraged to try it out and use it for new workloads. The old-style workload generation is still supported (see :ref:`defining-custom-workloads` for details).
Workloads are defined by a configuration file and corresponding workload source
directory, both typically in the
directory. Most paths in the configuration file are assumed to be relative to
the workload source directory.
Example Configuration File
FireMarshal supports many configuration options (detailed below), many of which
are not commonly used. We will now walk through an example that uses most of
the common options:
workloads/example-fed.json. In this example, we produce
a 2-node workload that runs two benchmarks: quicksort and spam-filtering. This
will require installing a number of packages on Fedora, as well as
cross-compiling some code. The configuration is as follows:
name field is required and (by convention) should match the name of the
configuration file. Next is the
base (fedora-base.json). This option
specifies an existing workload to base off of. FireMarshal will first build
fedora-base.json, and use a copy of its rootfs for example-fed before
applying the remaining options. Additionally, if fedora-base.json specifies any
configuration options that we do not include, we will inherit those (e.g. we
will use the
linux-config option specified by fedora-base). Notice that we
do not specify a workload source directory. FireMarshal will look in
workloads/example-fed/ for any sources specified in the remaining options.
Next come a few options that specify common setup options used by all jobs in
this workload. The
overlay option specifies a filesystem overlay to copy
into our rootfs. In this case, it includes the source code for our benchmarks
workloads/example-fed/overlay). Next is a
host-init option, this
is a script that should be run on the host before building. In our case, it
cross-compiles the quicksort benchmark (cross-compilation is much faster than
guest-init, this script should run exactly once natively within our
workload. For example-fed, this script installs a number of packages that are
required by our benchmarks. Note that guest-init scripts are run during the
build process; this can take a long time, especially with fedora. You will see
linux boot messages and may even see a login prompt. There is no need to login
or interact at all, the guest-init script will run in the background. Note that
guest-init.sh ends with a
poweroff command, all guest-init scripts should
include this (leave it off to debug the build process).
Finally, we specify the two jobs that will run on each simulated node. Job
descriptions have the same format and options as normal workloads. However,
notice that the job descriptions are much shorter than the basic descriptions.
Jobs implicitly inherit from the root configuration. In this case, both qsort
and spamBench will have the overlay and host/guest-init scripts already set up
for them. If needed, you could override these options with a different
option in the job description. In our case, we need only provide a custom
run option to each workload. The run option specifies a script that should
run natively in each job every time the job is launched. In our case, we run
each benchmark, collecting some statistics along the way, and then shutdown.
Finishing a run script with
poweroff is a common pattern that allows
workloads to run automatically (no need to log-in or interact at all).
We can now build and launch this workload:
./marshal build workloads/example-fed.json ./marshal launch -j qsort workloads/example-fed.json ./marshal launch -j spamBench workloads/example-fed.json
For more examples, see the
test/ directory that contains many workloads
used for testing FireMarshal.
FireMarshal was primarily designed to support linux-based workloads. However,
it provides basic support for bare-metal workloads. Take
This workload creates a simple "Hello World" bare-metal workload. This workload
simply inherits from the "bare" distro in its
base option. This tells
FireMarshal to not attempt to build any linux binaries or rootfs's for this
workload. It then includes a simple host-init script that simply calls the
makefile to build the bare-metal boot-binary. Finally, it hard-codes a path to
the generated boot-binary. Note that we can still use all the standard
FireMarshal commands with bare-metal workloads. In this case, we provide a
testing specification that simply compares the serial port output against the
known good output of "Hello World!".
A complete discussion of generating bare-metal boot-binaries is out of scope for this documentation.
Configuration File Options
Below is a complete list of configuration options available to FireMarshal.
Name to use for the workload. Derived objects (rootfs/bootbin) will be named according to this option.
Configuration file to inherit from. FireMarshal will look in the same directory
as the workload config file for the base configuration (or the workdir if
--workdir was passed to the marshal command). A copy of the rootfs from
will be used when building this workload. Additionally, most configuration
options will be inherited if not explicitly provided (options that cannot be
inherited will be marked as 'non-heritable' in this documentation).
In addition to normal configuration files, you may inherit from several hard-coded "distros" including: fedora, br (buildroot), and bare. This is not recommended for the linux-based distros because the fedora-base.json and br-base.json configurations include useful additions to get things like serial ports or the network to work. However, basing on the 'bare' distro is the recommended way to generate bare-metal workloads.
Path to binary for spike (riscv-isa-sim) to use when running this workload in spike. Useful for custom forks of spike to support custom instructions or hardware models. Defaults to the version of spike on your PATH (typically the one include with riscv-tools).
Path to riscv-linux source directory to use when building the boot-binary for
this workload. Defaults to the riscv-linux source submoduled at
Linux configuration file to use when building linux. Take care when using a custom configuration, FireSim may require certain boot arguments and device drivers to work properly.
A script to run natively on your host (i.e., your manager instance where you invoked FireMarshal) from the workload source directory each time you explicitly build this workload.
^^^^^^^^^^^^^^^ A script to run natively on the guest (i.e., your workload
running in qemu) exactly once while building. The guest init script will be run
from the root directory with root privileges. This script should end with a
poweroff to make the build process fully automated. Otherwise, the
user will need to log in and shut down manually on each build.
A script or command to run on the output of your run. At least the serial port output of
each run is captured, along with any file outputs specified in the
option. The script will be called like so:
cd workload-dir post_run_hook /path/to/output
The output directory will follow roughly the following format:
runOutput/name-DATETIME-RAND/ name-job/ uartlog OUTPUT_FILE1 ... OUTPUT_FILEN
When running as part of the
test command, there will be a folder for each
job in the workload.
Filesystem overlay to apply to the workload rootfs. An overlay should match the rootfs directory structure, with the overlay directory corresponding to the root directory. This is especially useful for overriding system configuration files (e.g. /etc/fstab). The owner of all copied files will be changed to root in the workload rootfs after copying.
A list of files to copy into the rootfs. The file list has the following format:
[ ["src1", "dst1"], ["src2", "dst2"], ... ]
The source paths are relative to the workload source directory, the destination paths are absolute with respect to the workload rootfs (e.g. ["file1", "/root/"]). The ownership of each file will be changed to 'root' after copying.
A list of files to copy out of the workload rootfs after running. Each path should be absolute with respect to the workload rootfs. Files will be placed together in the output directory. You cannot specify the directory structure of the output.
A script to run automatically every time this workload runs. The script will
run after all other initialization finishes, but does not require the user to
log in (run scripts run concurrently with any user interaction). Run scripts
typically end with a call to
poweroff to make the workload fully automated,
but this can be omitted if you would like to interact with the workload after
its run script has finished.
Unlike FireSim workloads, the FireMarshal launch command uses
the same rootfs for each run (not a copy), so you should avoid using
-f to prevent filesystem corruption.
A command to run every time this workload runs. The command will be run from
the root directory and will automatically call
poweroff when complete (the
user does not need to include this).
Directory to use as the workload source directory. Defaults to a directory with the same name as the configuration file.
Enable/Disable launching of a job when running the 'test' command. This is occasionally needed for special 'dummy' workloads or other special-purpose jobs that only make sense when running on FireSim. Defaults to 'yes'.
A list of configurations describing individual jobs that make up this workload.
This list is ordered (FireSim places these jobs in-order in simulation slots).
Job descriptions have the same syntax and options as normal workloads. The one
exception is that jobs implicitly inherit from the parent workload unless a
base option is explicitly provided. The job name will be appended to the
workload name when creating boot-binaries and rootfs's. For example, a workload
called "foo" with two jobs named 'bar' and 'baz' would create 3 rootfs's:
foo.img, foo-bar.img, and foo-baz.img.
Non-heritable: You cannot use jobs as a
base, only base workloads.
Explicit path to the boot-binary to use. This will override any generated binaries created during the build process. This is particularly useful for bare-metal workloads that generate their own raw boot code.
Explicit path to the rootfs to use. This will override any generated rootfs created during the build process. This is mostly used for debugging.
Provide details of how to test this workload. The
test command will ignore
any workload that does not have a
testing field. This option is a map with
the following options (only
refDir is required):
Path to a directory containing reference outputs for this workload. Directory structures are compared directly (same folders, same file names). Regular files are compared exactly. Serial outputs (uartlog) need only match a subset of outputs; the entire reference uartlog contents must exist somewhere (contiguously) in the test uartlog.
Maximum time (in seconds) that the workload should take to build. The test will fail if building takes longer than this. Defaults to infinite.
workloads with many jobs and guest-init scripts, could take a very long time to build.
Maximum time (in seconds) that any particular job should take to run and exit. The test will fail if a job runs for longer than this before exiting. Defaults to infinite.
Attempt to clean up the uartlog output before comparing against the reference. This will remove all lines not generated by a run script or command, as well as stripping out any extra characters that might be added by the run-system (e.g. the systemd timestamps on Fedora). This option is highly recommended on Fedora due to it's non-deterministic output.