Adding RP_choose function to change replacement policies among
TreePLRU, LRU, FIFO, LFU, LIP, MRU, NRU, RRIP, SecondChance AND ShiPMem replacement
policies for TCC, TCP and SQC caches for GPU
Change-Id: I86cc41cca19f8e0d24d8cf015e2e034a1fc4bc43
Adding RP_choose functions to change replacement policies among
TreePLRU, LRU, FIFO, LFU, LIP, MRU, NRU, RRIP, SecondChance AND ShiPMem replacement
policies for TCC, TCP and SQC caches for GPU
Adding RP_choose function to change replacement policies among
TreePLRU, LRU, FIFO, LFU, LIP, MRU, NRU, RRIP, SecondChance AND ShiPMem replacement
policies for TCC, TCP and SQC caches for GPU
Adding RP_choose functions to change replacement policies among
TreePLRU, LRU, FIFO, LFU, LIP, MRU, NRU, RRIP, SecondChance AND ShiPMem replacement
policies for TCC, TCP and SQC caches for GPU
Adding RP_choose functions to change replacement policies among
TreePLRU, LRU, FIFO, LFU, LIP, MRU, NRU, RRIP, SecondChance AND ShiPMem replacement
policies for TCC, TCP and SQC caches for GPU
When accessing memory using functionalAccess(), the MMU could tell us to
use a nonsecure access even though the CPU is operating in secure mode.
I noticed this while trying to run a simple semihosting hello world with
the MMU+caches enabled and the semihosting calls ended up reading from
memory instead of the caches due to an S/NS mismatch.
See also https://github.com/gem5/gem5/pull/1198 which happens to also
mask the issue I saw, but I believe both changes are needed.
Change-Id: I9e6b9839b194fbd41938e2225449c74701ea7fee
Some arithmetic instructions of the riscv vector extension where still
using the default VLEN=256 instead of the dynamic one through the
inherited `vlen` attribute. Most of them only use this to calculate the
effective index for the mask element like so:
```
uint32_t ei = i + vtype_VLMAX(vtype, vlen, true) * this->microIdx;
if (this->vm || elem_mask(v0, ei)) {
...
```
This means that instructions will wrongly compute the mask index in the
second and subsequent micro instructions (`microIdx` > 0). This commit
fixes this by adding the corresponding `set_vlen` snippet to the
affected instruction formats.
Change-Id: Ib041de972d6938490741a9fb4c214a6a5172c34e
While running a simple Arm32 binary, I noticed that all memory
transactions were being marked as NS instead of S once I turn on the MMU
(even though the page tables have the NS bit set to zero). The result of
this was that semihosting calls were failing since they were using
functional accesses with the SECURE flag set, but the caches only
contained NS tagged entries so these accesses always read stale values
from DRAM.
Digging through the Arm MMU code it appears that the NS bit lookup was
being keyed of the `secureLookup` flag which is only used for long
descriptors. I believe 0c28712f51 should
have used isSecure instead of secureLookup. To avoid using these
uninitialized values in the future I wrapped the LPAE state in a
std::optional to ensure that it is only accessed once initialized.
Change-Id: Ibc406ed3f4cfa768f470e34a5eca3c1a2bf45cd8
The SYS_WRITEC and SYS_WRITE0 calls are specified as writing to the
debug channel, so it is a reasonable expectation for these messages to
be visibile immediately after the semihosting call.
Change-Id: I8e6e9a7aab593a59e82ecb9cf4603c18c7a8acbe
Clang warns as follows: `warning: definition of implicit copy
constructor for 'TranslResult' is deprecated because it has a
user-declared copy assignment operator`
Change-Id: Ic701d8522aac75d569f4f513f54de91f76a17e48
`src/dev/virtio/VirtIORng 2.py` is identical to
`src/dev/virtio/VirtIORng.py`, and the former does not appear in any
build script.
Change-Id: I9c5f1b1a3809d1c7028b630c32310e540613e232
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
Fixed the assertion statement in the cpu's translation.hh file so that
it doesn't fail the assertion if the cache is clean.
I compile this c code to `test`
```c
#include <stdio.h>
static inline void clflush(volatile void *p) {
__asm__ volatile ("clflush (%0)" : : "r"(p) : "memory");
}
int main() {
int data = 42; // Example variable
printf("Value before clflush: %d\n", data);
clflush(&data);
printf("Value after clflush: %d\n", data);
return 0;
}
```
And run it with this script
`./build/X86/gem5.opt configs/learning_gem5/part1/two_level.py ./test`
In order to verify that it no longer fails the assertion check.
GitHub Issue: #862
Change-Id: I6004662e7c99f637ba0ddb07d205d1657708e99f
This feature has been available since Vega10 but was never implemented.
MI300 adds a few new instructions that make use of this more often
(e.g., v_mov_b64).
Change-Id: Ieeb7834462b76d77c0030f49622d0de09f90c9e4
This instruction is a simple move from accumulation register to
accumulation register. It is essentially a move with the accumulation
offset added to the register index.
Change-Id: Ic93ae72599b75c91213f56ebafe5bbd7b2867089
Flat, scratch, and global share the same instruction implementation with
different address calculations essentially. These instructions were
already implemented but not added to the decoder. This commit adds the
remaining scratch instructions which have a shared instruction
implementation.
Change-Id: I8f2e9ceb221294dce1b81c45745b642f0592d985
The lines `constexpr int B_I = std::ceil(64.0f / (N * M / H));` caused
the following compilation error in clang Version 16:
```
error: constexpr variable 'B_I' must be initialized by a constant
expression
```
`std::ceil` is not a const expression. Therefore instances of this
expression in instructions.hh have been replaced with a constant
expression friendly alternative.
This is calling our compiler tests to fail:
https://github.com/gem5/gem5/actions/runs/9288296434/job/25559409142
Change-Id: I74da1dab08b335c59bdddef6581746a94107f370
Currently when data is downgraded by MOESI_AMD_Base-CorePair (e.g. due
to a replacement) this requires a 4-way handshake between the CorePair
and the dir. Specifically, the CorePair send a message telling the dir
it'd like to downgrade then, the dir sends an ACK back and then, the
CorePair writes the data back, and finally, the dir ACKs the writeback.
This is very inefficient and not representative of how modern protocols
downgrade a request. Accordingly, this commits updates the downgrade
support such that the CorePair writes back the data immediately and then
the dir ACKs it.
Thus, this approach requires only a 2-way handshake.
Change-Id: I7ebc85bb03e8ce46a8847e3240fc170120e9fcd6
Co-authored-by: Neeraj Surawar <neerajs@hyrule.cs.wisc.edu>
When compiler tries to inline a vector construction with a default value
as default constructed ReplaceableEntry. It can complain about the
uninitialized member.
Let's provide basic initialization to the members.
Example codepath:
SignaturePathV2 constructor
-> GlobalHistoryEntry() as init_value to AssociativeSet
-> AssociativeSet initialize vector<Entry> with init_value
This PR is doing the following:
1) Fixing memory attributes of partial translation entries (table walks)
2) Properly setting the cacheability of table walks
Fix#1168. Prevent logical instructions like AND, OR, and TEST from
having input dependencies on the previous value of the Zaps register
(ZF+AF+PF+SF) by having them set AF=0, rather than not modifying AF.
* The GCC used in the GCN-GPU images was increase from version 8 to
version 10. This was necessary due to PR #1145 which made GCC require
GCC >=10. This patch was previously part of #1161 but has been merged
into
this PR.
* A patch has been applied to ROCm-OpenCL-Runtime to fix a linking error
in which there were multiple definitions of `ret_val`. This issue is
highlighted here:
https://github.com/ROCm/ROCm-OpenCL-Runtime/issues/113.
This was previously part #1161 but has been moved into this PR.
* The Dockerfile's `RUN` command (built to layers in the Docker image)
have been refactored so sources and built objects are deleted in the
same RUN command as where they were built and installed. This reduces
the size of the image substantially: from 16.3GB down to 6.6GB.
* The `apt upgrade` has been removed. This step (previously at the start
of the file) did nothing of importance. Removing it saves both time
building the image and reduces the size of the image by a small amount.
* `--depth=1` is used when cloning repositories so the entire commit
tree
tree is not pulled each time. This saves some time when building the
image.
* `apt -y update` has been added where `apt -y install` is used so
CACHED image layers do not become an issue in the future if the image
were to be rebuilt.
Fix#1169. Break the input dependency of 32-bit and 64-bit 'mov'
micro-ops on the prior value in the destination register. Such a
dependency is required for 8-bit and 16-bit moves, as they do not
completely overwrite the value in the destination register. However, it
is unnecessary for 32-bit moves (which implicitly zero the upper 32
bits) and 64-bit moves.
This patch implements the fix by adding a new code template field inside
the generated constructors of X86StaticInst's, called `invalidate_srcs`,
which instruction implementations like `mov` can use to conditionally
invalidate particular source registers as needed. In `mov`'s case, this
is when the data size is 32 or 64 bits.
Change-Id: Ib2aef6be6da08752640ea3414b90efb7965be924
SDMA RLC queues do not currently remove their doorbell mapping. This can
cause issues re-registering the queue and prevents the pending doorbells
feature from working. In addition the data value of the doorbell (the
ring buffer rptr) is not saved, leading to UB when this workaround is
used.
This commit removes the doorbell mapping from the gpu device when the
SDMA engine unmaps an RLC queue and copies the next doorbell value to
the pending packet as was originally intended.
Change-Id: Ifd551450f439c065579afcf916f8ff192e7598ab
According to the Arm architecture reference manual, it is possible to
force the broadcast of the following TLBIs:
AArch64: TLBI VMALLE1, TLBI VAE1, TLBI ASIDE1, TLBI VAAE1, TLBI VALE1,
TLBI VAALE1, IC IALLU, TLBI RVAE1, TLBI RVAAE1, TLBI RVALE1, and TLBI
RVAALE1.
AArch32: BPIALL, TLBIALL, TLBIMVA, TLBIASID, DTLBIALL, DTLBIMVA,
DTLBIASID, ITLBIALL, ITLBIMVA, ITLBIASID, TLBIMVAA, ICIALLU, TLBIMVAL,
and TLBIMVAAL.
Via the HCR_EL2.FB bit
Change-Id: Ib11aa05cd202fadfbd9221db7a2043051196ecbd
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
When determining the cacheability of table walks,
SCTLR.C should only be used in stage1 EL1&0 translations.
Stage2 translations should rely on HCR_EL2.CD instead
Change-Id: I1b0830bc3fb5086f68d7a7a1560c7fed5d126d28
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Make table walks uncacheable if marked as uncacheable
in either inner or outer shareable domain
Change-Id: I5898a3b91b5b919e0beda6c6fe896394e3ab94df
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The Daily Tests are failing when downloading artifacts as part of the
`testlib-long-tests` matrix:
https://github.com/gem5/gem5/actions/runs/9250821764/job/25448583827.
It _could_ be that since upgrading to `actions/download@v4`, we're
hitting a limit as the `testlib-long-tests` are downloading every gem5
binary compiled in the `build-gem5` step, each with it's own
`actions/download` step, for every test.
This change adds a small job after `build-gem5` which creates a merged
artifact containing all the gem5 binaries then uses this to lessen the
number of times this action is called in such a short period of time.
Even if the bug still persists, this solution is neater than what was
there previously.
StoreThrough in VIPER when the TCP is disabled, GLC bit is set, or SLC
bit is set will bypass the TCP, but will temporarily allocate a cache
entry seemingly to handle write coalescing with valid blocks. It does
not attempt to evict a block if the set is full and the address is
invalid. This causes a panic if the set is full as there is no spare
cache entry to use temporarily to use for DataBlk manipulation. However,
a cache block is not required for this.
This commit removes using a cache block for StoreThrough with invalid
blocks as there is no existing data to coalesce with. It creates no
allocate variants of the actions needed in StoreThrough and pulls the
DataBlk information from the in_msg instead. Non-invalid blocks do not
have this panic as they have a cache entry already.
Fixes issues with StoreThroughs on more aggressive architectures like
MI300.
Change-Id: Id8687eccb991e967bb5292068cbe7686e0930d7d
Those AArch64 instructions/registers were labelled as executable
from EL3 only if SCR_EL3.NS == 1. This is not valid anymore
after the introduction of FEAT_SEL2
The new static analysis in GCC 13 finds issues with operand.hh. This
commit fixes the error so that gem5 compiles when BUILD_GPU is true.
Change-Id: I6f4b0d350f0cabb6e356de20a46e1ca65fd0da55
Those AArch64 instructions/registers were labelled as executable
from EL3 only if SCR_EL3.NS == 1. This is not valid anymore
after the introduction of FEAT_SEL2
Change-Id: Ie7b56f3fe779c3a99d4f0ef937c7c8ec0530b00e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This is making it easier for TLBI instructions to share code. Common
code (under the form of tlbi* functions) are closely matching the
instruction description in the Arm pseudocode
Change-Id: If10c22fb4a7df2bcd0335e9761286ad3c458722b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The bit 0 of register should be 0 for jump address. Wrong handling the
jump address may cause infinite run or segment fault.
gem5 issue: https://github.com/gem5/gem5/issues/981
Fixed the issue that did not allow building TLM.
Build commands:
```bash
scons build/ARM/gem5.opt
scons setconfig build/ARM USE_SYSTEMC=n
scons --with-cxx-config --without-python --without-tcmalloc build/ARM/libgem5_opt.so
cd util/tlm
scons
```
Following this README, I tested it successfully with the simple examples:
https://gem5.googlesource.com/public/gem5/+/master/util/tlm/README
GitHub Issue: #591
Change-Id: If07fae2eb20ad62627e733573f61bc42d594f970
---------
Co-authored-by: Ivana Mitrovic <ivanamit91@gmail.com>
note: Due to #556 / #555, we don't support GCC 9. This PR removes gcc-8
which means gem5 would support GCC >= version 10.
The reason for removing gcc-8:
1. We already dropped support for gcc-9. I don't see any good reason to
support anything <9 as a result.
2. GCC is relatively old, and we're probably supporting a bit too many
compiler versions anyway. In Ubuntu 22.04, gcc-11 is downloaded by
default with `apt`. It doesn't seem many system are still using gcc.
3. There is a weird compiler bug in gcc-8 which is causes failure when
compiling gem5 since the inclusion of #1123. The error received is as
follows:
```sh
In file included from src/arch/riscv/tlb.hh:42,
from src/arch/riscv/mmu.hh:45,
from build/ALL/arch/riscv/generated/exec-g.cc.inc:14,
from build/ALL/arch/riscv/generated/generic_cpu_exec.cc:5:
src/arch/riscv/utility.hh: In instantiation of ‘FloatType gem5::RiscvISA::ftype(IntType) [with FloatType = float8_t; IntType = unsigned char]’:
build/ALL/arch/riscv/generated/exec-ns.cc.inc:38839:42: required from ‘gem5::Fault gem5::RiscvISAInst::Vfwcvt_xu_f_vMicro<ElemType>::execute(gem5::ExecContext*, gem5::trace::InstRecord*) const [with ElemType = float8_t; gem5::Fault = std::shared_ptr<gem5::FaultBase>]’
build/ALL/arch/riscv/generated/exec-ns.cc.inc:38856:16: required from here
src/arch/riscv/utility.hh:327:15: error: parameter ‘a’ set but not used [-Werror=unused-but-set-parameter]
ftype(IntType a) -> FloatType
~~~~~~~~^
src/arch/riscv/utility.hh: In instantiation of ‘IntType gem5::RiscvISA::f_to_wui(FloatType, uint_fast8_t) [with FloatType = float8_t; IntType = short unsigned int; uint_fast8_t = unsigned char]’:
build/ALL/arch/riscv/generated/exec-ns.cc.inc:38838:49: required from ‘gem5::Fault gem5::RiscvISAInst::Vfwcvt_xu_f_vMicro<ElemType>::execute(gem5::ExecContext*, gem5::trace::InstRecord*) const [with ElemType = float8_t; gem5::Fault = std::shared_ptr<gem5::FaultBase>]’
build/ALL/arch/riscv/generated/exec-ns.cc.inc:38856:16: required from here
src/arch/riscv/utility.hh:570:20: error: parameter ‘a’ set but not used [-Werror=unused-but-set-parameter]
f_to_wui(FloatType a, uint_fast8_t mode)
```
Note: This is currently causing our SST Daily tests to fail, and our
compiler tests to fail.
