This commit added two paramaters in the set_se_binary_workload to pass
input parameters for the binary.
The "arguments" object allows users to pass in arugments in a list.
The "stdin_file" object allows users to pass in input file as a
Resource.
This commit also created a local variable "binary_path" to save the
return object of "binary.get_local_path()".
Note:
These new parameters were tested and passed in 4 cases:
1. only passing in (Resource/CustomResource) binary
2. passing in (CustomResource) binary and input_file
3. passing in (CustomResource) binary and argument(no input file
directory included)
4. passing in (CustomResource) binary and argument(with input file
directory included)
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1242
Change-Id: I6433a349f7ecb5d630c7cdbe7268ff18915bf23f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61609
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
This option doesn't work and triggers a warning by Linux when booting.
To make it work, we need a chosen node containing an `stdout-path`
property in the FDT which currently doesn't exist.
I tried to create via a couple of approaches it but encountered multiple
issues:
1. One can set `stdout-path` to the complete path of the tty device, but
such path is impossible to get programmatically (unless it's
hardcoded).
2. One can set `stdout-path` as a reference to a label. While labels are
possible to generate easily, reference to labels cannot be generated
with the current FDT library.
So just remove this option for the time being.
Change-Id: I58ad879c0fdf567a812069ae91ebc7d4f8accf13
Signed-off-by: Joël Porquet-Lupine <joel@porquet.org>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61534
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This commit imported the warn from m5.util library and added a function
named "defaultBehaviorWarning" to the exit_event_generators.py file
under src/python/gem5/simulator.
This function takes two string variable and output a warning that
contains a warning about the default behavior, the behavior type,
and an detail explaination about it.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1235
Change-Id: I54500425eaa1a556769aa1f8ea6b32852694c94d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61189
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Change word "unavaiable" to "unavailable".
When kvm_required is set to True in requires() from gem5.utils.requires
and KVM is not available on the host system, print "KVM is required but
is unavailable on this system" instead of ""KVM is required but is
unavaiable on this system".
Change-Id: I483fb75a6a4781560ae338370ba2714fd8737cc6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61169
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
For SimObject type param, we should avoid duplicated addChild
call if it already belongs to other parent.
In the original implementation, the following code:
```
class A(SimObject):
...
class B(SimObject):
a = Param.A(...)
class Top(RealView):
a = A()
b = B(a=a)
```
will generate incorrect warning:
```
warn: <orphan B>.a already has parent not resetting parent.
Note: a is not a parameter of B
warn: (Previously declared as <orphan Top>.a)
```
The code tries to add `a` as the child of `Top` as well as child of
`Top.b`, which is incorrect.
Change-Id: I8c55c5dd4cc0dd45c68169a2b08450ff053c07aa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60789
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Base on https://graphviz.org/doc/info/shapes.html#record, record shape
has problems with edge between adjacent nodes on the same rank. This will
produce message "flat edge between adjacent nodes one of which has a record
shape" and dump a huge svg file in gem5's stdout. Also, the edge will
not be plotted in the output svg.
By looking at out dot_writer, we don't really use any record specific
label. As a result, we can simply apply box as the shape to achieve the
same output without the strange error message.
Change-Id: Ibbbcbfbc29edcd64bfeb7ae10adccfb54ea2613a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60749
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
The previous version of this requires the user to set the `main-isa` at
runtime, as inplemented via
https://gem5-review.googlesource.com/c/public/gem5/+/55423. In order to
keep this work in-sync with how the multi-protocol approach will work
(see here: https://gem5-review.googlesource.com/c/public/gem5/+/59193),
it's been decided this should be set at compile time. With this we are
keeping the `TARGET_ISA` parameter. If this is set, this is the de
facto "main-isa". The `main-isa` parameter has been removed from the
gem5 command-line.
If the `TARGET_ISA` parameter is not set, but only one ISA is compiled,
then this single ISA is assumed to be the `main-isa` for simulation. If
neither `TARGET_ISA` is set or the binary is compiled to a single ISA,
an exception is thrown when `get_runtime_isa` is called.
At the time of writing this change is moot as the multi-isa work has
yet to be merged into the gem5 develop branch. It exists here:
https://gem5.googlesource.com/public/gem5/+/refs/heads/multi-isa and
will need refactored to work with this patch.
The multi-isa tests have been updated. As we no longer pass the
`main-isa` as a run-time parameter, we remove many tests which validated
this use-case.
Change-Id: If3366212fe1dacbae389efa43d79349deb907537
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59949
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
This change modifies the Simulator constructor to optionally
take a checkpoint directory as an input so that the m5 can
instantiate from the saved checkpoint.
A new method is also added to the Simulator class. The function
will save the checkpoint to the specified directory.
Change-Id: I58b686b6b4f69260ab45709c6ef0bddf4539f0c4
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58789
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Add GenericRiscvPciHost to RISCV Board. In addition, we connect the IGbE_e1000
ethernet card to PCI in order to verify the correct functionality.
To be noticed that we build a new Linux kernel v5.10 (with Bootloader) according to these steps (
https://github.com/gem5/gem5-resources/tree/stable/src/riscv-fs) adding the the PCI and e1000 drivers:
CONFIG_PCI_SYSCALL=y
CONFIG_PCI_STUB=y
CONFIG_PCI_HOST_GENERIC=y
CONFIG_NET_VENDOR_INTEL=y
CONFIG_E1000=y
CONFIG_E1000E=y
CONFIG_IGB=y
CONFIG_NET_VENDOR_I825XX=y
Here you can find the kernel.config and our prebuild kernel to verify the correct behaviour:
https://www.dropbox.com/scl/fo/sz9s37vybpfecbfilxqzz/h?dl=0&rlkey=klkxh33anjqnzwj3sopucqqzx
You can verify it with the following command:
build/RISCV/gem5.fast configs/example/gem5_library/riscv-fs.py
Dear Jason Lowe-Power,
Thank you for your comments! We have addressed all of them.
Best regards,
Nikolaos Tampouratzis
Dear Jason,
I think that it is ok now! :)
Thanks!
Best regards,
Nikolaos Tampouratzis
Change-Id: Id27d84a5588648b82cbfd5c88471927157ae6759
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59969
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 changes adds a new board to the gem5 stdlib, which is capable
of simulating an ARM based full system. It also adds an example
config script to perform a boot-test using an Ubuntu 18.04 disk
image. A test has been added in the gem5-library-example for the
same.
Change-Id: Ic95ee56084a444c7f1cf21cdcbf40585dcf5274a
Signed-off-by: Kaustav Goswami <kggoswami@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58910
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
In the prior design the AbstractBoard inherited from System. This was
fine for the X86Board and RISCVBoard, but was causing problems for the
design of the ARMBoard which must inherit from ArmSystem (which itself
inherits from System).
This new design removes the System inheritance from AbstractBoard, and
creates a new "AbstractSystemBoard" class which inherits from both
AbstractBoard and System. This allows for the creation of an ArmBoard
which inherits from both AbstractBoard and Arm System.
Change-Id: I3831f2ebe61e4adfb9dc10b7790b39403a99beaa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58909
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
If Ruby is disabled, then RubyNetwork is not a SimObject, and
do_ruby_dot which tries to reference it will crash. This more flexibly
checks for RubyNetwork, and if that isn't in m5.objects will gracefully
return instead of crashing.
Also streamline the code in that function a little bit using filter()
instead of preconstructing the list of ruby networks.
Change-Id: Ia4bdb04201df8453a1b6692a2f211b6cde00be2d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59629
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Via the "GEM5_RESOURCE_JSON" environment variable, a user can override
the the default resources.json retrieval location. E.g., a user can have
their own resources.json file and load it instead. This may be a local
file path or a URL.
Code has been changed in downloader.py to allow the loading of
resources.json from either a URL or a local file path. Previously only
URLs were valid.
Change-Id: I022eee58efadc4819069563e9046ce9d84e5cf06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59069
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, if you try to instantiate an abstract SimObject the error is
confusing and unhelpful.
"TypeError: _m5.param_<type>.<type>Params: No constructor defined!"
Now, it will instead say "Cannot instantiate an abstract SimObject"
and include the name of the object that causes the error.
Change-Id: Ia8c51e29dccd999ec90dcd39710cc91d9a5fb86f
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59049
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Found via a failing weekly test:
https://jenkins.gem5.org/job/weekly/46/
The following exception was thrown:
```
FileExistsError: [Errno 17] File exists: '/nobackup/jenkins/workspace/weekly/tests/gem5/resources'
At:
/usr/lib/python3.8/os.py(228): makedirs
build/GCN3_X86/python/gem5/resources/resource.py(156): __init__
/nobackup/jenkins/workspace/weekly/tests/gem5/configs/x86_boot_exit_run.py(192): <module>
build/GCN3_X86/python/m5/main.py(440): main
```
It was found that, in cases where the resource directory does not exist,
there is a race condition between gem5 threads to create the directory.
This patch fixes this so threads that lose this race continue normally.
Change-Id: Ie3323c4df0b247e7830c5d3ab93a4d7f9224fe36
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59090
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The downloader briefly caches the resources.json file in "/tmp". This
works fine if the system only has one user, but in a system supporting
many users, where "/tmp" is shared, there were permission issues when a
user tried to access a resources.json cache from another user. To
resolve this the uid of the user is appended to the filename.
Change-Id: Iba8ab12cd7054c2f5636e444ac0f1f8f73fedc89
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58489
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 two functions are `get_cpu_types_str_set()` which returns a set of
valid CPUTypes as strings, and `get_cpu_type_from_str()` which will
return a CPUType enum given an input string.
The purpose of these functions is to aid and standardize user input
parameters or environment variables.
Test scripts are updated accordingly.
Change-Id: I7cb9263321fe36bc8a7530edfd0d8e8bbd329e0e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58491
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The main restriction with this design is it results in one ISA target
per board. The ISA is declared per core. To make the design simpler it's
assumed a Processor (a collection of cores) are all of the same ISA. As
each board has one processor, this also means a board is typically tied
to one ISA per simulation.
In order to remain backwards compatible and maintain the standard
library APIs, this patch adds a `--main-isa` parameter which will
determine what `gem5.runtime.get_runtime_isa` returns in cases where
mutliple ISAs are compiled in. When setting the ISA in a simulation (via
the Processor or Cores), the user may, as before, choose not to and, in
this case, the `gem5.runtime.get_runtime_isa` function is used.
The `gem5.runtime.get_runtime_isa` function is an intermediate step
which should be removed in future versions of gem5 (users should specify
precisely what ISA they want via configuration scripts). For this reason
it throws a warning when used and should not be heavily relied upon. It
is deprecated.
Change-Id: Ia76541bfa9a5a4b6b86401309281849b49dc724b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55423
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
