The WriteUniqueZero is an immediate write to a Snoopable address region
that does not require any data transfer (cacheline is zeroed)
Change-Id: Ia8c9b40e08a3b7d613f0b62ce0ac4b0547860871
Reviewed-by: Tiago Muck <tiago.muck@arm.com>
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
These tests previously used "build/NULL" but due to changes in the
"Ruby" and "garnet_synth_traffic.py" scripts, "NULL" fails as the script
exists "X86TimingSimple" with MESI_Two_Level.
This change fixes the tests by compiling and using the correct
compilation of gem5. It shouldn't affect the tests in any negative way.
As far as I'm aware it does not matter what ISA is used for these tests.
Change-Id: I8ae84b49f65968e97bef4904268de5a455f06f5c
configs/ruby/Ruby.py fails when `DerivO3CPU` is not compiled into the
gem5 binary. The `isinstance` check fails. This fix addds a guard.
Change-Id: I1e5503ab18ec94683056c6eb28cebeda6632ae8e
- This script copies all resources from a mongodb database locally The
script creates a resources.json and downloads all the resources. It also
updates the resources.json to point to these local downloads instead of
the cloud bucket.
Change-Id: I15480c4ba82bbf245425205c9c1ab7c0f3501cc3
Note: A bug was identified in that the one of the special file paths,
namely /proc/meminfo contained an extra trailing /, implicitly making
the incorrect assumption that meminfo was a directory, when it is, in
fact, a (pseudo-)file. This was causing application in SE mode to fail
opening the meminfo pseudo-file with errno 13. This commit fixes this
issue.
Change-Id: I93fa81cab49645d70775088f1e634f067b300698
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Stash requests will simply be discarded by the Home Node This will
return a CompI response to the RNF
Change-Id: I9c2ce5d4d42f380d1a554933d381cf8a8590ba22
Reviewed-by: Tiago Muck <tiago.muck@arm.com>
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
There were two small bugs preventing gem5 from obtaining Looppoint
resources.
1. When obtained via a `WorkloadResource` there was an assert which
assumed the values in the resource's DB entry's `additional_parameter`
field were of type string. This is not the case. For Looppoint resources
there are additional parameters which are arrays.
2. Due to changes introduced in https://github.com/gem5/gem5/pull/625,
the Looppoint CSV and JSON files were not being downloaded when needed.
This was fixed by replacing access to the `local_path` variable with a
call to `get_local_path()`.
Because each vector load is fragmented into 64 byte cache-aligned
chunks, and one page-table walk is issued per fragment on tlb miss,
walks start to accumulate on a pending queue, which is processed in a
blocking way (no pending walks can be issued while one is being
processed). This adds noticeable latency on vector loads when VLEN is
sufficiently large.
This commit fixes the issue by allowing walks to be squashed if a TLB
lookup hits just before starting the walk on `startWalkWrapper`. This
idea was taken from the ARM walker.
Due to a change introduced in https://github.com/gem5/gem5/pull/625, a
gem5 resource will not download any external files until
`get_local_path()` is called. In the construction of the Looppoint
Resources this function was not called, the `local_path` variable was
called directly. As such, an error occured.
The downside of this fix is the Looppoint resources external files are
downloaded when `obtain_resource` is called, thus the bandwidth savings
introduced with https://github.com/gem5/gem5/pull/625 will not occur for
Looppoint resources. However, https://github.com/gem5/gem5/issues/644
proposes a fix which would supercede the
https://github.com/gem5/gem5/pull/625 solution.
Change-Id: I52181382a03e492ec1cb58b01e71bc4820af9ccc
The value of a `WorkloadResource`'s additional parameter may not always
be a string. It can be any JSON value (integer, a list, a dict, ect.).
For Looppoint resources we have additional parameters such as a List of
region start points.
The assert inside workloads checking the type of the value breaks
certain usecase and is therefore removed in this commit.
Change-Id: Iecb1518082c28ab3872a8de888c76f0800261640
The stats initialization in the AbstractMemory allocates the space
according to the max requestors of the System. This may cause issues in
multiple system simulation.
Given there are two system A and B. A has one requestor and a memory,
while B has two requestors. When the requestor with requestor id 2
sending requests to the meomry in A, the simulator would crash because
requestor id 2 is out of the allocated space.
Current solution is adding a SysBridge between across A and B which
would rewrite the requestor id to a valid one. This solution works but
it needs to the bridge at the correct boundary which may not easy. In
addition, the stats would record a mapped data which may not accurate.
To reduce the complexity, we add an flag to AbstractMemory to control
the stats. If users don't want the statistics and want to solve the
cross system issue simply, users can disable the statistics collection.
We also makes the flag by default True to not disturb current users.
Correct the instruction flags of RISC-V vector store instructions, such
as `vse64_v`, `vse32_v`. The `vse64_v` in `decoder.isa` is
`Mem_vc.as<uint64_t>()[i] = Vs3_ud[i];` and it will generate the code
`Mem.as<uint64_t>()[i] = Vs3[i];`. The current regex of assignRE only
mark the operand `Mem` as `dest` only if meet the formats like `Mem =
Rd` or `Mem[i] = Rd` because the code ` = Rd` or `[i] = Rd` match the
`assignRE` respectively. For the expression `Mem.as<uint64_t>()[i]`, the
operand `Mem` will falsely mark the operand as `src` because the code
`.as<uint64_t>()[i]` is not match the `assignRE`.
The PR will ensure the operand `Mem` is dest for the format like
`Mem.as<xxx>()[i] = yyy`.
Correct the instruction flags of RISC-V vector store instructions, such
as `vse64_v`, `vse32_v`. The `vse64_v` in `decoder.isa` is
`Mem_vc.as<uint64_t>()[i] = Vs3_ud[i];` and it will generate the code
`Mem.as<uint64_t>()[i] = Vs3[i];`. The current regex of assignRE only
mark the operand `Mem` as `dest` only if meet the formats like `Mem = Rd`
or `Mem[i] = Rd` because the code ` = Rd` or `[i] = Rd` match the
`assignRE` respectively. For the expression `Mem.as<uint64_t>()[i]`,
the operand `Mem` will falsely mark the operand as `src` because the
code `.as<uint64_t>()[i]` is not match the `assignRE`.
The PR will ensure the operand `Mem` is dest for the format like
`Mem.as<xxx>()[i] = yyy`.
Change-Id: I9c57986a64f1efb81eb9c7ade90712b118e0788d
Inspired by the similar feature in ARM's full system workload, this
change adds
an option to halt gem5 simulation if the guest system encounter kernel
panic
or kernel oops.
On RiscvISA::BootloaderKernelWorkload, by default, the simulation
will exit upon kernel panic, while kernel oops will not induce
simulation halt.
This is because the system will essentially do nop after a kernel panic,
while the
system might be still functional after a kernel oops.
Dumping kernel's dmesg is useful for diagonizing the cause of kernel
panic, so
ideally, we want to dump the guest's dmesg to the host. However, due to
a bug
described in [1], kernel v5.18+ dmesg might not be dumped properly.
Hence, the
dmesg will not be dumped to the host.
On RiscvISA::FsLinux, this feature is turned off by default as the
symbols from the
official RISC-V kernel resource are stripped from the binary. However,
if this feature
is enable, the dmesg will be dumped to the host system.
[1] https://github.com/gem5/gem5/issues/550
Change-Id: I8f52257727a3a789ebf99fdd4dffe5b3d89f1ebf
1. Fix the wrong ISA detect of get_isa function
2. Fix the typo ObjectLIst.cpu_list
3. Fix missing PageTableWalkerCache
4. Fix the invalid default cpu_type paramter
Change-Id: I217ea8da8a6d8e712743a5b32c4c0669216ce6c4
The stats initialization in the AbstractMemory allocates the space
according to the max requestors of the System. This may cause issues in
multiple system simulation.
Given there are two system A and B. A has one requestor and a memory,
while B has two requestors. When the requestor with requestor id 2
sending requests to the meomry in A, the simulator would crash because
requestor id 2 is out of the allocated space.
Current solution is adding a SysBridge between across A and B which
would rewrite the requestor id to a valid one. This solution works but
it needs to the bridge at the correct boundary which may not easy. In
addition, the stats would record a mapped data which may not accurate.
To reduce the complexity, we add an flag to AbstractMemory to control
the stats. If users don't want the statistics and want to solve the
cross system issue simply, users can disable the statistics collection.
We also makes the flag by default True to not disturb current users.
Change-Id: Ibb46a63d216d4f310b3e920815a295073496ea6e
This includes mla/s index version implementation using the existing template code
to avoid code repeatition.
Change-Id: If1de84e01dec638e206c979ca832308ebc904212
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>
Inspired by a similar feature in ARM's full system workload, this change adds
an option to halt gem5 simulation if the guest system encounter kernel panic
or kernel oops.
On RiscvISA::BootloaderKernelWorkload, by default, the simulation
will exit upon kernel panic, while kernel oops will not induce simulation halt.
This is because the system will essentially do nop after a kernel panic, while the
system might be still functional after a kernel oops.
Dumping kernel's dmesg is useful for diagonizing the cause of kernel panic, so
ideally, we want to dump the guest's dmesg to the host. However, due to a bug
described in [1], kernel v5.18+ dmesg might not be dumped properly. Hence, the
dmesg will not be dumped to the host.
On RiscvISA::FsLinux, this feature is turned off by default as the symbols from the
official RISC-V kernel resource are stripped from the binary. However, if this feature
is enable, the dmesg will be dumped to the host system.
[1] https://github.com/gem5/gem5/issues/550
Change-Id: I8f52257727a3a789ebf99fdd4dffe5b3d89f1ebf
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
Co-authored-by: Jason Lowe-Power <jason@lowepower.com>
`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.
clang correctly found that the functions `inCache`, `hasBeenPrefetched`
and `inMissQueue` had the wrong signatures in the DVM funcs files. These
functions are unused, so this change just updates their signatures.
Change-Id: Id669ff661e1c6c46eaf04ea1f17cd9866a9e49ed
- updated the x86-npb-benchmarks.py to use npb workloads and suites.
The suites and workloads are not in the database are also waiting
feedback. I am attaching the JSON file here.
[npb_workloads_suite.json](https://github.com/gem5/gem5/files/13431116/npb_workloads_suite.json)
To run the x86-npb-benchmarks.py script use the
GEM5_RESOURCE_JSON_APPEND env variable. The full command is:
```
GEM5_RESOURCE_JSON_APPEND=[path to npb_workloads_suite.json] ./build/X86/gem5.opt configs/example/gem5_library/x86-npb-benchmarks.py --benchmark [benchmark]
```
Change-Id: I248e6452ea4122e9260e34e4368847660edae577
Currently, if the Capstone header file is found in the host system,
scons will try to build the ArmCapstoneDisassembler regardless of the
gem5 target ISA. This is causing problem when the host has Capstone, but
the gem5 target ISA is not arm. Compiling gem5 in this case will cause
errors, e.g., ArmISA and ArmSystem is not found.
This change aims to prevent building the ArmCapstoneDisassembler when
the gem5 target ISA is not arm.
Ref:
[1] The Arm Capstone PR https://github.com/gem5/gem5/pull/494
Change-Id: I1e714d34aec8fe2a2af8cd351536951053a4d8a5
This Pull-Request addresses gem5 Issue #550. The code that dumps the
Dmesg buffer is now templated on the two variants of the `Metadata`
structure, and the correct one is chosen based on the detected Kernel
version.
To support this functionality, the pull request also adds Symbol Size
data to the loader Symbol Table, and adds a method to query the Kernel
Version from the image in guest memory. The new attributes in the Symbol
class are de-serialized speculatively, so no checkpoint upgrader is
required to support this change.
This patch reworks the Linux Kernel panic and oops events. The code has
been re-factored to provide re-usable events that can be applied to all
ISAs from the base `KernelWorkload` `SimObject`. At the moment they are
installed for the Arm workloads.
This update also provides more configuration options that can be
specified using the new `KernelPanicOopsBehaviour` enum. The options are
applied to the Kernel Workload parameters `on_panic` and `on_oops` which
are available to all subclasses of `KernelWorkload`.
The main rationale for this reworking is to add the option to cleanly
exit the simulation after dumping the Dmesg buffer. Without this option,
the simulation would continue running after a Kernel panic. If system
components (e.g. a system timer) keep the event queue alive, this causes
the simulation to run slowly to the maximum allowed tick.
