This commit adds the senvcfg CSR, which fixes the 6.11.3 kernel
crash documented in issue 1674. I have not added a bitfield and
its implementation in isa.cc only uses setMiscRegNoEffect, so
this implementation is likely missing some critical components.
The previous #484 issue reported a bug where the TLB stats on RISC-V
were incremented twice on misses by calling the `lookup` function twice
with hidden argument set to `false`. The fix is only applied on atomic
mode as the `translation` argument of `doTranslate` will not be
`nullptr` in timing mode.
In that case, if the TLB lookup miss, the `doTranslate` function will
start the walker and then return without doing anything more. Then
later, when the pagetable walker found the corresponding PTE, it will
insert it and call `translateWithTLB`. This function then call `lookup`
again which will hit in any case (and crash if not due to the following
assert), but the hit count is incremented here too.
This commit fix by setting the `hidden` argument of `lookup` to true.
GCC and CLANG have different annotations for declaring code should not
be optimized. Adding GEM5_NO_OPTIMZE provides gem5 developers a MACRO
that works in both cases.
This change replaces the GCC pragmas in vfp.hh with GEM5_NO_OPTIMIZE
as this solution didn't work with clang.
In MI_example, when in MI state the block "Maybe_Stale" as in this
controller may have the most up to date value or it could be in the
network. For MII it is guaranteed that this controller has the most up
to date value because it received a PUTX_NACK.
This fixes one of the daily test failures.
- In the new MultiRuby system, the generated ProtocolInfo header files were not being correctly added to the build targets in SCons.
- As a result, when building gem5 with the --duplicate-sources option, these files were mistakenly deleted by SCons.
This happened because SCons treated them as source files instead of generated build targets.
- This commit ensures that the ProtocolInfo header files are explicitly included in the build targets, preventing their unintended removal and fixing the build issue.
The test `ruby_test_test-ALL-x86_64-opt-MatchStdout` is currently
failing because the reference file doesn't match the actual output. This
PR changes the reference file to match.
Fix#1809. Shift the mmap end to a lower address in case the process has
a large max stack size, to avoid overlapping the stack with the mmap
memory range.
Change-Id: Idae343dbbe851a7510463ff141c03f1847e36328
Previous PR #1758 implements the generic getValidAddr to get pure
vaddr without any tags or sign-extend bits.
In RISC-V implementation, the getValidAddr will zero-extend
address in RV32 mode and use it to do TLB translation. Use
getValidAddr to get zero-extend vaddr can reduce zero-extend
repetition
Change-Id: I2273ce48bccb873790103ba0fcdb0b48de9ced4c
src/cpu/simple/probes/LooppointAnalysis.py:
- remove default values for bb_valid_addr_range and
marker_valid_addr_range
- add more comments to explain parameter behaviors
- add citation to the LoopPoint paper
src/cpu/simple/probes/looppoint_analysis.cc:
- fix the incorrect styles
- remove updateBackwardBranch() function call
- match the style of checking if listeners vector is empty
- change the way of stopListening() to remove the listeners through the
manager instead of through the ProbeListener object's destructor.
src/cpu/simple/probes/looppoint_analysis.hh:
- removed backwardBranchPC and use the backwardBranchCounter to replace
its functionaility. Therefore, also removed updateBackwardBranch
function.
Change-Id: Id2430e2f04e61f72d5c4f1aad5cfd4d24a0fbc45
Add comments to most variables and functions.
Change the naming of some variables and functions to improve the
clearness.
Change-Id: Idb557ec84698b4344ed4683f5de87b1a3c2fd66d
In looppoint_analysis.hh, added LooppointAnalysis and
LooppointAnalysisManager classes.
Added all functions and variables for the classes.
Comments needed.
Change-Id: Ia7425b672ef092a68c99b702136850bfa1fcf0a2
Because the LoopPoint analysis will be done with ATOMIC CPU, so all
files related to the LoopPoint analysis object will be under
/src/cpu/simple/probes.
Change-Id: Icbdb0742b712a23dc8f6a19f4c1c827a1f5bf288
This change updates the names for the GPU children in a better way than
overriding the parent. Now it looks something like
```text
board.gpus.shader.CUs00
board.gpus.gpu_caches.ruby_gpu.controllers02
board.gpus.memory.mem_ctrl0
```
Note that it is "gpus" with an "s" because the board accepts more than 1
GPU, optionally.
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This function returns the GPUs (for now, possibly other devices in the
future). It needs to be in the abstract board so the GPU-specific cache
hierarchies can be used with non-GPU boards.
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This prepends loading the GPU drivers to anything passed in via the
readfile_contents. Note that if the user sets a specific readfile via a
file they will be responsible for loading the driver
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This change separates the instantiation of gpu memory from
instantiatiing the gpu cache. Prior to this change, the gpu
cache instantiated the memories for the gpu by receiving number
of channels as a parameter. With this change, the gpu memory
should be constructed outside the gpu, without being added as a
child to any other object, and passed to the constructor of
the gpu.
This change adds a new method to AbstractMemorySystem to allow
getting its objects of the class MemInterface. This is useful
when certain other classes require a list of MemInterface objects
to create physical memory. In addition, ChanneledMemory and
HighBandwidthMemory implement this function.
Adds GPU_VIPER protocol related caches to stdlib components: CorePair
cache, TCP, SQC, TCC, Directory, and DMA controllers. Adds GPU related
components in a new components/devices/gpus/ directory. Adds prebuilt
GPU and CPU cache hierarchies, GPU and CPU network classes, and a board
overriding the X86Board to provide helper methods for disk image root,
the complex kernel parameter list, and method to provide functionality
to the current GPUFS scripts to load in applications and handle loading
the GPU driver.
The new GPU components can be used as follows:
- Create a GPU device *before* the CPU cache hierarchy is created.
- Add the GPU's CPU-side DMA controllers to the list of CPU cache
controllers.
- Use GPU device method to connect to an AbstractBoard.
Each GPU components has it's own RubySystem, PCI device ID, and address
ranges for VBIOS and legacy PCI BARs. Therefore, in theory, multiple
GPUs can be created. This requires PR #1453 .
An example of using this board is added to configs/example/gem5_library
under x86-mi300x-gpu.py. It is designed to work with the disk image,
kernel, and applications provided in the gem5-resources repository.
Change-Id: Ie65ffcfee5e311d9492de935d6d0631260645cd3
This commit is adding two python files:
* ruby_mem_test.py is the canonical gem5 configuration script,
and it is an adaptation of the existing ruby_mem_test.py [1].
The main difference is the use of the TlmController as a
cache controller, and the use of TlmGenerator instead of
the MemTest memory tester. The config is minimally setting up
the system. The extent of the testing is specified in the second
python file:
* read_shared_unit.py: "unit-test" for the CHI ReadShared request
The file should be passed to the ruby_mem_test.py as cmdline
argument:
build/ARM/gem5.opt <>/ruby_mem_test.py <>/read_shared_unit.py
This is a simple testing file. We should ideally generate separate
test files for separate transactions/scenarios.
The test file can have whatever for inside, it only needs to comply
to the minimal interface required by the ruby_mem_test.py, which is
to define the following function:
def test_all(generator):
[1]: https://github.com/gem5/gem5/blob/stable/\
configs/example/ruby_mem_test.py
Change-Id: I767ede9b8572f3eafe677c84da45fd904d77e319
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit is building over the CHI-TLM wrapping introduced
by the previous commit and it is adding a CHI traffic generator
as a SimObject.
This will get the python objects as input and it will forward
them to the TlmController to convert them into ruby CHI
messages
Change-Id: Ia67094c9bb880e37b24184313df546ecbaa3289f
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit is wrapping the external AMBA CHI-TLM with pybind11
so that it will be possible to use its data structures/functions
from python.
More specifically we will be able to instantiate a ARM::CHI::Payload
and ARM::CHI::Phase from a gem5 config, with the end goal of being
able to configure a CHI transaction from python
Change-Id: I9587b445c21df44161fa3d9e09fc2651541b38bd
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit is extending the previously defined CHIGenericController
to implement a CacheController which acts as a bridge between the
AMBA TLM 2.0 implementation of CHI [1][2] with the gem5 (ruby) one.
In other words it translates AMBA CHI transactions into ruby
messages (which are then forwarded to the MessageQueues)
and viceversa.
ARM::CHI::Payload, CHIRequestMsg
<--> CHIDataMsg
ARM::CHI::Phase CHIResponseMsg
CHIDataMsg
[1]: https://developer.arm.com/documentation/101459/latest
[2]: https://developer.arm.com/Architectures/AMBA#Downloads
Change-Id: I6f35e7b4ade4d0de1b5e5d2dbf73ce796a9f9fb6
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit allows top level configs making use of the Ruby module
to define node generation callbacks.
The config_ruby function will check the system object for two
factory methods
1) _rnf_gen, if defined, will be called to generate RNFs
2) _mn_gen, if defined, will be called to generate MNs
Change-Id: I9daeece646e7cdb2d3bfefa761a9650562f8eb4b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Component implementing a generic controller that allow classic caches
interaction with Ruby/CHI.
The CHIGenericController provides an interface to send/receive CHI
messages to/from the interconnect. This is implement in C++ rather then
SLICC. This controller is seen as a MachineType:Cache by the CHI
implementation in SLICC.
Change-Id: I3afc4363f4290095c2f7428c8487bccd932e0300
