There have been failures on the weekly tests during the decoding of the
downloaded resources.json base64 file. These errors suggested an
incomplete download or some form of file corruption. These errors only
ever seem to occur when multiple threads of gem5 are running. It has
therefore been proposed that perhaps, in some cases, the cached
downloaded file was bring re-downloaded while also being read by
another thread. For this reason this patch adds a filelock so only one
instance of gem5, at any one time, can download and read the
resources.json file. Even if this is not the cause of the weekly test
errors, it still adds some additional safeguards.
Change-Id: I7c6e1c1786c1919e8519587e53b6a77f4aafa932
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57789
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
"resources.json" is referenced when a resource is requested. The
"resources.json" file may be updated at any time and therefore, the
downloader was engineered to retrieve this file from the gem5-resources
repo on each request. However, this can lead to excessively frequently
pulls over short periods of time which is uncessary given how
infrequently this file changes.
To combat this, this patch caches the "resources.json" file and will
use it for up to an hour after creation before re-retrieving it.
Change-Id: I3b4907cbadce8a54df21d85f8021bf3603ae0f6f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57275
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
On occasion HTTP status codes, such as 429, are returned when
downloading the resources and/or the "resources.json" file. In such
cases it makes sense to retry the download.
This patch adds a Truncated Exponential Backoff algorithm to the
downloader to retry downloads, with a default maximum of 6 attempts.
This is done in cases where HTTP status codes 408, 429, and 5xx are
returned.
So this feature is applied to both the retrieval of the resources and
the "resource.json" file, the downloading of the "resources.json" file
has been modified to utilize the `_download` function as is used to
download resources
Change-Id: Ic4444b52f0f71d294fccec9de3140beece5f7576
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/57274
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It appears that there is a mechanism where you could either have a .m5
directory in your home directory, or set an M5_CONFIG environment
variable to some other directory, where you could put an options.py
file. That file would then be passed the options dict which gem5's main
had extracted from its args, which it could modify as it liked.
First, I suspect that this mechanism was basically unknown and was just
a dark corner of gem5 people had forgotten about. Getting rid of it
will help clear out old cruft.
Second, this sort of file reaching in and fiddling with gem5's internal
data structures is dangerous and fragile, and could in almost any case
be replaced with a wrapper script or shell alias.
Change-Id: Ic828716979ea6379f60de796d23281ab075b38ec
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56387
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Systemd, which is used by many main stream Linux distributions,
will lead to slow boot if entropy is low. On X86 platforms,
this problem can be alleviated by enabling RDRAND instructions.
However, RISC-V doesn't have similar instructions. For QEMU/KVM,
this problem can be solved by passing randomness from the host
via virtio_rng. But gem5 doesn't have VirtIORng support now.
Some user report that the boot time of riscv-ubuntu-run.py is
too long. To alleviate this problem, this patch add VirtIORng
device support for gem5.
Change-Id: Id93b5703161701212fd6683837034cb0cff590c5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55483
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The `get_simstat` function in `src/python/m5/stats/gem5stats.py` was
returning an error when a non-Root Simobject was passed:
```
AttributeError: object 'PyTrafficGen' has no attribute 'name'
At:
build/NULL_MESI_Two_Level/python/m5/SimObject.py(1430): __getattr__
build/NULL_MESI_Two_Level/python/m5/stats/gem5stats.py(279): get_simstat
```
The issue was an assumption that SimObjects have a field `name`. They
do not. To get a SimObject's name the `get_name()` function must be
used. This patch fixes this issue.
In addition to this fix, the documentation in this function has been
improved to state more clearly what can be passed and what shall be
returned. Previously it was somewhat unclear.
Change-Id: I33538120015280bb6260ccf8eba6b75ff43d280e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54943
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The 'resources.json' file in gem5 resources is used to lookup resources.
The stdlib resource downloader was hardcoded to the 'resources.json'
stored in the gem5 resources stable branch. This change allows the gem5
downloader to obtain the specific resources.json.
Change-Id: Ie119ed9326b359055bf5bc347ca89336a5cc2e5d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54466
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This CustomResource can be used to specify a custom, local disk image.
It allows the user to specify the disk root partition parameter
considerably easier than when setting a disk image through a
CustomResource.
Change-Id: I8189ad065124d028aea9fab1c7f07108aa4ce6d5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53844
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
CustomResource's base class, AbstractResource, must be constructed with
a dictionary for the 'metadata' field. However, if the user did not
specify any metadata for the CustomResource, None is passed. This is
not permitted and can cause error. This patch ensures the metadata is
set to an empty dictionary by default
Change-Id: I358725ee6982dc9c6410eac3ad8194fa676dd326
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53843
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Like gem5py which uses the same main source file, this program will run
arbitrary python scripts. Unlike the other program, it will include
support for the m5 module. That will make it capable of generating
SimObject param, enum, etc c++ files.
Change-Id: I15fd7545f6b1ea6559cbe27cef30c778867ebe70
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49421
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
By separating out this utility class, we make it possible to build
embedded python modules into other binarys without dragging along lots
of other, unrelated gem5 dependencies.
Also, move the class from sim/init.hh (which is a largely unrelated
name) to python/embedded.hh which much more directly describes what that
file contains.
Change-Id: Ia83439144893ad8401a5d51003e2686d9c9b2d7b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49418
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously, the importer module was built into gem5 as a compressed
bytecode blob like all the other code, and it had to be singled out and
installed manually so that it could help bring in all the other modules.
That adds some amount of complexity since it has to be identified and
treated as a special case.
Instead, this change builds it into gem5 using pybind11's
PYBIND11_EMBEDDED_MODULE macro, and a string that gets evaluated into
the new module's __dict__. This means the importer module is
automatically available just by building in that .cc, and it can just be
imported to start using it.
Theoretically all the embedded python could be handled this way, but
that would mean building it into gem5 as raw strings which wouldn't even
be compiled into byte code until run time. That would take more space in
the binary, and also delay catching simple errors.
Change-Id: Ic600bf6bce41a53289a2833484a655dd5a226e03
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49410
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This serves two purposes. First, it's a way to declare the base
SimObject class and params using the SimObject() SCons mechanism, while
the actual class still lives at m5/SimObject.py.
Second, it alleviates a very old inconsistency where *most* SimObjects
are imported using the m5.objects.Foo path, except SimObject itself
which lives under m5.SimObject. With this change, it will live under
both, more or less.
It may be possible to remove the inconsistency entirely in the future
and move m5.SimObject entirely to m5.objects.SimObject and only declare
it with SCons's SimObject(), but that won't quite work during this
transitional period, and it wouldn't give users a chance to move over to
the new name.
Change-Id: Ic714bacfaef73d1116ab7ff716cf19b7ce4b67e1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49408
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This added both the LupioPIC and LupioTMR to the LupVBoard. While
both the PLIC and CLINT are left in the board for the bootloader
to recognize, they aren't used within the system. In addition, the
LupV Platform was changed in order to use the LupioPIC to handle
interrupts instead of the PLIC.
Change-Id: I57005903a7ec1136b42433ef5022ccb995abb9d6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53037
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This LupV Board was created in order to connect all of the LupIO
devices, and allow us to run a full RISC-V system with them. As
the LupIO devices continue to be added, they will be integrated
into this board, and replace the current IO components.
The LupIO devices are a collection of processor
agnostic and easily implemented virtual devices. Details about the
specifications of all eight LupIO devices can be found here:
https://gitlab.com/luplab/lupio/lupio-specs
Information about how to build a RISCV full system with the LupIO-RTC
can be found here:
https://github.com/darchr/lupio-gem5/blob/lupio/README.md
Change-Id: I7d3186d3778d40b38027f245290432dbf4279dea
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53028
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change removes the code base for SingleChannelMemory and
replaces it with MultiChannelMemory. muli_channel defines all
the classes that were defined by single_channel. Basically any
SingleChannelMemory could be thought of as a MultiChannelMemory
with 1 channel.
Change-Id: If96079d5f77be5a3ba26d2c2ddb98f5c60375cd8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/53304
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This change updates the constructor for MultiChannelMemory. The
constructor now assumes every input parameter is of type string
and casts them to proper types inside the function. This way
the MultiChannelMemory could be tested easier. Considering that
tests might not want to pass in all the arguments and might use
argparser to read the inputs.
Change-Id: I80786066ccbb9cb1b7111831d9bc9d95e5204f40
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52904
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
This changeset adds CHI support in the components library. Currently,
only a very simple one level protocol is implemented, but hopefully this
design will be able to scale to other more complex hierarchies.
I've tested this with RISC-V with 1 and 4 cores and with x86 with 1
core. Since we don't have an Arm-compatible board, I haven't tested with
ARM. Note that x86 with more than 1 core boots most of the way, but it
hangs during systemd (the kernel comes up completely).
Change-Id: I56953238c6b0ca5ac754b103a1b6ec05a85a0af5
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52463
Reviewed-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
`setup_memory_ranges()`, now `_setup_memory_ranges()`, had to be called
by subclasses. Since `setup_memory_ranges() was always called at the top
of the `_setup_board()` function (or could be), this function is now
automatically called within the AbstractBoard's constructor prior to
`_setup_board` and `_connect_things`.
Change-Id: I6bf3231666b86059ffc484cfca44e45cfde52ea6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52883
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
