RISCV full system workloads have the capability of exit the simulation loop
upon the guest's kernel panic/oops. This change adds more stdlib exit event types
to accommodate the corresponding gem5 exits upon the guest's kernel panic and
kernel oops.
Change-Id: I3a4f313711793a473c6f138ff831b948034d0bb6
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
`get_runtime_isa()` has been deprecated for some time. It is a leftover
piece of code from when gem5 was compiled to a single ISA and that ISA
used to configure the simulated system to use that ISA. Since multi-ISA
compilations are possible, `get_runtime_isa()` should not be used.
Unless the gem5 binary is compiled to a single ISA, a failure will
occur.
The new proceedure for specify which ISA to use is by the setting of the
correct `BaseCPU` implementation. E.g., `X86SimpleTimingCPU` of
`ArmO3CPU`.
This patch removes the remaining `get_runtime_isa()` instances and
removes the function itself. The `SimpleCore` class has been updated to
allow for it's CPU factory to return a class, needed by scripts in
"configs/common".
The deprecated functionality in the standard library, which allowed for
the specifying of an ISA when setting up a processor and/or core has
also been removed. Setting an ISA is now manditory.
Fixes#216.
The [PR](https://github.com/gem5/gem5/pull/390) adds support for new
bootloader and linux kernel. However after applying the changes the
arguments are not passed correctly to the kernel resulting in kernel
panic during simulations. This commit fixes the issue.
This change decouple's the downloading of a resource from it's data.
With this change the `obtain_resource` function returns the
`AbstractResource` implementation which contains the data. The resource
itself (e.g., the actual disk image, binary, file, etc.) is only
downloaded to the host system, if not already present, upon the
`get_local_path` call.
`get_local_path` is the function used by gem5 to ultimately load the
resource into a simulation, therefore this change ensures we only
download resources when they are loaded into a simulation.
This change is not ideal and comes with the following caveats:
1. The `downloader` function is created in `obtain_workload` and passed
to the `AbstractResource` implementation for later use. This function
comes with the following requirements:
* The function will download the resource to `local_path`.
* The function will not re-download the resources if already present
as this function is called _everytime_ `get_local_path` is called.
2. The directories needed to store `local_path` are created in
`obtain_workload` regardless. Ergo even if the resource is not used and
`get_local_path` is never called these directories are still created.
In keeping with this efficiency `ShadowResource` is introduced to allow
the storing of just the resource ID and Version of a resource with
additional information only obtained when requested.
This change does the following,
- Change the name of several python parameter names of the
RiscvBootloaderKernelWorkload. This is done to conform the expectation
from the stdlib, e.g., the kernel path must be `object_file`, and the
boot parameter must be `command_line`.
- Use RiscvBootloaderKernelWorkload by default for all full system
RISC-V simulations. RiscvBootloaderKernelWorkload is a superset of
RiscvFsWorkload.
The purpose of a `ShadowResource` is a resource which only contains the
ID and Version information, not any additional information about the
resource thus avoiding the `obtain_resource` call.
When attributes of the `ShadowResource` are accessed which can only be
obtained via `obtain_resource` the `ShowResource` calls the function and
returns what is required.
This is useful for `Suite` resources which contain several workloads
and resources which may not all be needed when the `Suite` object is
first instantiated.
Change-Id: Icc56261b2c4d74e4079ee66486ddae677bb35cfa
This change decouple's the downloading of a resource from it's data.
With this change the `obtain_resource` function returns the
`AbstractResource` implementation which contains the data. The resource
itself (e.g., the actual disk image, binary, file, etc.) is only
downloaded to the host system, if not already present, upon the
`get_local_path` call.
`get_local_path` is the function used by gem5 to ultimately load the
resource into a simulation, therefore this change ensures we only
download resources when they are loaded into a simulation.
This change is not ideal and comes with the following caveats:
1. The `downloader` function is created in `obtain_workload` and passed
to the `AbstractResource` implementation for later use. This function
comes with the following requirements:
* The function will download the resource to `local_path`.
* The function will not re-download the resources if already present
as this function is called _everytime_ `get_local_path` is called.
2. The directories needed to store `local_path` are created in
`obtain_workload` regardless. Ergo even if the resource is not used and
`get_local_path` is never called these directories are still created.
Change-Id: I3f0e9a0099cba946630d719c3d17b7da0bccf74a
- The resources field in workload now changed to a dict of id and
version from a string with just the id.
There was an if statement added to support both versions in develop.
Removing the if statement so that 23.1 supports the new changes only.
Change-Id: Id8dc3f932f53a156e4fb609a215db7d85bd81a44
The CL updates the Kconfig:
1. Replace the USE_NULL_ISA with BUILD_ISA
2. The USE_XXX_ISAs are depends on BUILD_ISA
3. If the BUILD_ISA is set, at least one of USE_XXX_ISAs must be set
4. Refactor the USE_KVM option
Change-Id: I2a600dea9fb671263b0191c46c5790ebbe91a7b8
- resources field in workload now supports a dict with resources id and
version.
- Older workload JSON are still supported but added a deprecation waring
Recent breaking changes in the DRAMSys API require user code to be
updated. These updates have been applied to the gem5 integration.
Furthermore, as DRAMSys started to use CMake dependency management,
it is no longer sensible to maintain two separate build systems for
DRAMSys. The use of the DRAMSys integration in gem5 will therefore
from now on require that CMake is installed on the target machine.
Additionally, support for snapshots have been implemented into DRAMSys
and coupled with gem5's checkpointing API.
arch-riscv: Fix implementation of CMO extension instructions
This change introduces a template for store instruction's mem access.
The new template is called CacheBlockBasedStore.
The reasons for not reusing the current Store's mem access template
are as follows,
- The CMO extension instructions operate on cache block size
granularity,
while regular load/store instructions operate on data of size 64 bits or
fewer.
- The writeMemAtomicLE/writeMemTimingLE interfaces do not allow passing
nullptr as data. However, CPUs in gem5 rely on (data == NULL) to detect
CACHE_BLOCK_ZERO instructions. Setting `Mem = 0;` to `uint64_t Mem;`
does not solve the problem as the reference is allocated and thus,
it's always true that `&Mem != NULL`. This change uses the
writeMemAtomic/writeMemTiming interfaces instead.
- Per CMO v1.0.1, the instructions in the spec do not generate
address misaligned faults.
- The CMO extension instructions do not use IMM.
---
arch-riscv: Fix generateDisassembly for Store with 1 source reg
Currently, store instructions are assumed to have two source registers.
However, since we are supporting the RISC-V CMO instructions, which
are Store instructions in gem5 but they only have one source register.
This change allows printing disassembly of Store instructions with
one source register.
---
arch-riscv: Make Zicbom/Zicboz extensions optional in FS mode
Currently, we're enable Zicbom/Zicboz by default. Since those
extensions might be buggy as they are not well-tested, making
those entensions optional allows running simulation where
the performance implication of the instructions do not matter.
Effectively, by turning off the extensions, we simply remove
those extensions from the device tree, so the OS would not
use them. It doesn't prohibit the userspace application to
use those instructions, however.
---
arch-riscv: Add all supporting Z extensions to RISC-V isa string
Previously, opening a config file (such as
`configs/example/hmc_hello.py`) containing non-ASCII characters causes
UnicodeDecodeError.
Also switch to use more an more idiomatic context manager for handling
files.
Change-Id: Ia39cbe2c420e9c94f3a84af459b7e5f4d9718d14
- resources field in workload now supports a dict with resources id
and version.
- Older workload JSON are still supported but added a deprecation waring
Change-Id: I137dbb99799a5294e84ce7d5d914f05e4cfe9e00
Currently, we're enable Zicbom/Zicboz by default. Since those
extensions might be buggy as they are not well-tested, making
those entensions optional allows running simulation where
the performance implication of the instructions do not matter.
Effectively, by turning off the extensions, we simply remove
those extensions from the device tree, so the OS would not
use them. It doesn't prohibit the userspace application to
use those instructions, however.
Change-Id: Ib30e98c4c39f741dec5f7d31bd7b832391686840
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
Currently, we are hardcoding the ISA string in the device tree
generator. The ISA string from the device tree affects which
ISA extensions will be used by the bootloader/kernel.
This function allows generating the ISA string from the gem5's
ISA object rather than using hardcoded values.
This series of changes also correct a couple of hardcoded
RISC-V ISA strings in the standard library, as well as not
enable RVV instructions for the U74 core model.
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
This is a temporary solution to fix daily tests. We could revert
to the default (policy_type = 1) once the problem is properly
fixed
Change-Id: Ia80af9a7d84d5c777ddeb441110a91a1680c1030
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
gem5 will otherwise fatal with the error message:
fatal: ... alloc_on_atomic without default or user set value
See github issue [1] for further details
[1]: https://github.com/gem5/gem5/issues/449
Change-Id: I0bb8fccf0ac6d60fc6c1229436a35e91b2fb45cd
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Current hardcoded value does not support vector instructions.
The new ISA string generator function allows the flexibility
of using or not using the vector extension.
Change-Id: Ic78c4b6629ad3813fc172f700d77ea956552e613
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
The return address stack (RAS) is restructured to be a separate SimObject.
This enables disabling the RAS and better separation of the functionality.
Furthermore, easier statistics and debugging.
Change-Id: I8aacf7d4c8e308165d0e7e15bc5a5d0df77f8192
Signed-off-by: David Schall <david.schall@ed.ac.uk>
In commit bbc301f2f0 the generalized
`Exception` was changed back to the more specific `HTTPError`.
In this case we do not desire specific error handling. If the connection
to the database fails I want the exception handled in the way outlined:
i.e., i want the connection to be retried 4 times before giving up. With
`HTTPError`, only `HTTPError`s warrent a retry.
Changing this to `HTTPError` cause tests to fail due to a failure to
retry downloading of a resource. Here is an example:
https://github.com/gem5/gem5/actions/runs/6521543885/job/17710779784
In this case `request.urlopen` raised a `URLError`. I suspect this was
some issued to do with reaching the DNS servers. It likely would've
succeeded if it had just tried again.
With -m, you can now run a module from the command line that is embedded
in the gem5 binary.
This will allow us to put some common "scripts" in the stdlib instead of
in the "configs" directory.
Now:
* The Atlas Client will attempt a connection 4 times, using an
exponential backoff approach between attempts.
* When a failure does arise a rich output is given so problems can be
easily diagnosed.
Addresses: #340
Now:
* The Atlas Client will attempt a connection 4 times, using an
exponential backoff approach between attempts.
* When a failure does arise a rich output is given so problems can be
easily diagnosed.
Change-Id: I3df332277c33a040c0ed734b9f3e28f38606af44
Added a parameter (_disk_device) to kernel_disk_workload which allows
users to change the disk device location. get_disk_device() now chooses
between the parameter and, if no parameter was passed, it calls a new
function _get_default_disk_device() which is implemented by each board
and has a default disk device according to each board, eg /dev/hda in
the x86_board. The previous way of setting a disk device still exists as
a default, however, with the new function users can now override this
default
This comment was left in the codebase in error. The
`set_se_binary_workload` function works fine with multi-threaded
applications. This hasn't been a restriction for some time.
- A new abstract BTB class is created to enable different BTB
implementations. The new BTB class gets its own parameter
and stats.
- An enum is added to differentiate branch instruction types.
This enum is used to enhance statistics and BPU management.
- The existing BTB is moved into `simple_btb` as default.
- An additional function is added to store the static instruction in
the BTB. This function is used for the decoupled front-end.
- Update configs to match new BTB parameters.
Change-Id: I99b29a19a1b57e59ea2b188ed7d62a8b79426529
Signed-off-by: David Schall <david.schall@ed.ac.uk>
This enables two things,
- /chosen/stdout-path is now default to uart@10000000, meaning
the linux kernel's boot console will be redirected to uart.
- /chosen/bootargs now contains the boot arguments obtained from
gem5's library. This allows passing the boot arguments to the
linux kernel via the device tree.
Change-Id: I53821d85f619e6276da85f41c972c041eaaf3280
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
