This PR is offloading some of the partitioning logic to the partitioning
manager, effectively changing
the partitioning interface. Rather than always relying on the
PartitionFieldExtention data structure to
convey partition IDs, we make it implementation defined by introducing
the partitioning manager abstraction.
We want user to be able to extract the partitionId more flexibly and
this requires using a SimObject.
Users can extend the PartitioningManager, overriding the
readPacketPartitionId, therefore providing their
own mean of injecting/extracting partitioning data from a packet
M5Ops C / C++ functions partially use 64 bit arguments and return value.
In general, 64 bit arguments and return values are possible for 32 bit
RISC-V systems as well, since the arguments and the return value is
split into two registers. However, at the moment, this does not work for
32 bit RISC-V systems on the simulator side, since there is a one to one
mapping between argument registers and m5op function parameters.
To solve this problem, the get() function of the RISC-V reg_abi is
updated. It now will merge two registers if there is a 64 bit argument.
For this, the function code has to be passed to the get() function. The
default value of this function code is set to 0xF00, since 0x00 is
already used for M5_ARM. The parameter list of other get() functions for
argument return is also extended by this function code parameter with
the keyword [[maybe_unused]].
To enable a return value of size 64 bit, a0 is assigned with the lower
32 bit and a1 with the higher 32 bit.
Related Issue: https://github.com/gem5/gem5/issues/881
The new ISA-agnostic interface is the PartitionManager.
We therefore make the PartitionFieldExtention private to the
Arm implementation of memory partitioning (FEAT_MPAM)
Any other partitioning implementation should override the
PartitionManager::readPacketPartitionID to provide a mean
for extracting partitioning data (partition_id) from the
incoming Packet.
With this commit we also define an MPAM MSC which is
supposed to be the partitioning manager for the
Memory System Component
Change-Id: I6959ace0c0cbca549dcc1aacd53dff223b5fe328
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This SimObject can be used to quickly test the statistics are
functioning correctly. The SimObject schedules a single event which sets
the statistics to values dependent on the SimObject params.
With this commit the "Scalar" stats have a StatTester subclass that can
be used for testing. More can be added as required.
Tests are included to check our Scalar SimStat functionality.
This has the SimObjects defined in "src/test_objects" only be compiled
into the gem5 binary if the Kconfig 'USE_TEST_OBJECTS" == 'y'. This
happens in two cases:
1. When 'ALL/gem5' is compiled via "build_opts".
2. When tests are run via "./tests/main.py".
Change-Id: I2330008fd7c7900de5f4de142b8ac89ef4e351ce
This SimObject can be used to quickly test the statistics are
functioning correctly. The SimObject schedules a single event which sets
the statistics to values dependent on the SimObject params.
With this commit the "Scalar" stats have a StatTester subclass that can
be used for testing. More can be added as required.
Tests are included to check our Scalar SimStat functionality.
Change-Id: I78fa5d9a0c3fc7115bd6c6d3410a5436aaa47f55
When the `statistics::nozero` flag is set gem5 does not output that stat
if its value is zero. This was not the case for SimStats which output in
this case. This patch correct this behavior.
This will just call the _m5.range.isSubset method
Change-Id: If747819a008a8ed20796b4efd42a42e5c3a8d7d9
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This is a followed up fix to #791 mem-ruby: Fix possible dirty line loss
in CHI when ReadShared hit on UD line.
UD_RU line may have stale data since the upstream could have updated the
line, so its local cache line data is treated as invalid
(dataValid=false). But when the line is evicted, it must be written back
to downstream because the upstream may have the line in clean state
(UC). This change fixes it by performing copy back the UD_RU line while
keeping its dataValid as false.
Example error case:
- L3 was in UD_RSC and being evicted without back-invalidation. LLC (HN)
was in RU state.
- Because there's still upstream sharer, L3 sends WriteClean.
- Because the data state was unique and dirty, L3 sends CBWrData_UD_PD.
- LLC becomes UD_RU.
- When the line is evicted from LLC (LocalHN_Eviction), the line is just
dropped, causing the loss of the dirty copy
Co-authored-by: Minje Jun <minje.jun@samsung.com>
The `reset_vect` has exist for a long time and `reset_vect` will not
effect if the user gonna to use customized reset_vect. The CL added the
`auto_reset_vect` to let the config determine the `reset_vect` from
workload entry point or user-specified
Ref: https://gem5-review.googlesource.com/c/public/gem5/+/42053
Change-Id: I928c0dc42aaa85ceabf8d75f9654486496e0ffee
This change sets the `release` of the ARM board at the config file
instead of overriding the release on the ArmBoard. This change partially
solves issue 932 as the system taking and restoring the checkpoint is
consistent across KVM and timing CPUs respectively.
Signed-off-by: Kaustav Goswami <kggoswami@ucdavis.edu>
Fix#988. Rewrite statxFunc and copyOutStatxBuf to use platform-agnostic
stat system call, not Linux-specific statx system call.
Change-Id: I3d17e14684e9cd77cdbfd0141b93c3bcbd27dbeb
When running `scons build/ALL/gem5.opt --with-ubsan`, with GCC, the
following error was returned:
```
[ CXX] src/base/loader/image_file_data.cc -> ALL/base/loader/image_file_data.o
In file included from /usr/include/string.h:535,
from /usr/include/c++/11/cstring:42,
from src/base/cprintf_formats.hh:33,
from src/base/cprintf.hh:38,
from src/base/logging.hh:49,
from src/base/loader/image_file_data.cc:40:
In function ‘char* strcpy(char*, const char*)’,
inlined from ‘int gem5::loader::doGzipLoad(int)’ at src/base/loader/image_file_data.cc:70:11,
inlined from ‘gem5::loader::ImageFileData::ImageFileData(const string&)’ atsrc/base/loader/image_file_data.cc:116:24:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:79:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ offset [0, 19] is out of the bounds [0, 0] [-Werror=array-bounds]
79 | return __builtin___strcpy_chk (__dest, __src, __glibc_objsize (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
scons: *** [build/ALL/base/loader/image_file_data.o] Error 1
scons: building terminated because of errors.
```
As can be seen from this Daily test log:
https://github.com/gem5/gem5/actions/runs/8478384881, checkout@v2 and
{upload/download}-artifact@v3 was causing warnings to be thrown. This
fix upgrades all instances of these actions to the latest version (in
both cases, v4).
Currently, the citation string has a Unicode character. This works well
in gem5, but it breaks the gem5+SST simulation [1]. This change modifies
the letter "u" with umlaut to use TeX's escape sequence for this letter
instead of using the UTF-8 character.
[1] https://github.com/gem5/gem5/issues/982
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
A constructor is added to GuestAddr as suggested in the pull request
feedback. This allows a cast conversion from uint64_t GuestAddr. Hence,
the casting from uint64_t to GuestAddr by reinterpret_cast is removed
(was added in a previous commit).
using namespace pseudo_inst is also removed as requested.
Comments are added to GuestAddr.
Change-Id: Ib76de2bff285f4e53ad03361969c27f7bb2dfe9e
AMD's MI100 introduced a new register file called accumulation registers
for the matrix cores. In MI200 these were recombined into the same
register file according to the documentation. The accumulation register
file is the same size as the architectural register file, hence the size
is doubled.
The ISA spec does not explicitly state the register selector values,
however it does say that the accumulation offset from the kernel
dispatch packet should be added to the architecture register file
selector number when an instruction sets the ACC bit. Therefore we can
infer that the value must simply be an extension beyond the
architectural VGPRs.
This fixes errors of the form "invalid register selector: 512" (or
higher value). This was tested with the Learn the Basics tutorial
example on pytorch.org
Change-Id: I48ced1532fc166d2f5032fe21fbeba70ac77f258
v3 was causing a 'Node.js 16 actions are deprecated' error.
Note: download-artifact@v4 must be used with upload-artifact@v4 and
vice-versa.
Change-Id: Icb8ab6d27aed4557be95ce31dd89d4655010968e
This caused a 'Node.js 16 actions are deprecated;' error.
With this commit all our checkout actions are set to '@v4'.
Change-Id: I0f931bf7967f49ee44b7bf1d6a56e19f017fb948
This address, 0x0, is most likely a wrong address to call m5 ops.
The warning will catch the problem where m5op_addr is not initialized
properly.
Change-Id: I442b4806191ae6f5c137bc947f2a269684c599dd
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
The existing implementation of vfmv instruction did not type cast the
first element of the source vector, which caused the "freg" to interpret
the result as a NaN.
With the type cast to f32, the value is correctly recognized as float
and sign extended to be stored in the fd register.
Git issue: https://github.com/gem5/gem5/issues/827
Change-Id: Ibe9873910827594c0ec11cb51ac0438428c3b54e
---------
Co-authored-by: Debjyoti B <bhatta53@imec.be>
Co-authored-by: Tommaso Marinelli <tommarin@ucm.es>
As pointed out here [1], the expected M5OP_ADDR for arm64 arch
is 0x10010000. This change reflects that.
[1] https://github.com/gem5/gem5/pull/725
Change-Id: I7e72f5ea20d4aacf3115a485ba7cd664d33d037e
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
Remove the following files:
* src/dev/virtio/rng 2.cc
* src/dev/virtio/rng 2.hh
Which were a copy of rng.hh and rng.cc. Probably added to the repository
by accident. They were not compiled by scons
Change-Id: I9d1da19cc243c513ab7af887b1b6260d8e361b57
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This is a first step towards offloading some of the partitioning
logic to the partitioning manager. We start with this patch
by replacing the static readPacketPartitionId into a virtual
method owned by the manager.
The issue with readPacketPartitionId as of now is that it relies
on the fixed PartitionFieldExtention.
We want user to be able to extract the partitionId more flexibly
and this requires using a SimObject
Change-Id: I3bd2e81e2a97c55fc83548956fc59f422c8049a6
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This PR fixes#948 in which running KVM CPUs through the updated gem5
interface in SE mode causes an immediate crash.
To fix this, I added a check to set_se_binary_workload that checks if
any of the cores are KVM, and if so, sets a couple of knobs for the
board and process that are required to make KVM work. The depecated
se.py script, which sets these knobs, is able to run KVM in SE mode just
fine, so doing the same here fixed the bug.
When running `scons build/ALL/gem5.opt --with-ubsan`, with GCC, the
following error was returned:
```
[ CXX] src/base/loader/image_file_data.cc -> ALL/base/loader/image_file_data.o
In file included from /usr/include/string.h:535,
from /usr/include/c++/11/cstring:42,
from src/base/cprintf_formats.hh:33,
from src/base/cprintf.hh:38,
from src/base/logging.hh:49,
from src/base/loader/image_file_data.cc:40:
In function ‘char* strcpy(char*, const char*)’,
inlined from ‘int gem5::loader::doGzipLoad(int)’ at src/base/loader/image_file_data.cc:70:11,
inlined from ‘gem5::loader::ImageFileData::ImageFileData(const string&)’ atsrc/base/loader/image_file_data.cc:116:24:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:79:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ offset [0, 19] is out of the bounds [0, 0] [-Werror=array-bounds]
79 | return __builtin___strcpy_chk (__dest, __src, __glibc_objsize (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
scons: *** [build/ALL/base/loader/image_file_data.o] Error 1
scons: building terminated because of errors.
```
I do not know the exact issue but using strcpy in this way (i.e.
`strcpy(char_pointer + offset, string)`) appears to trigger this error
with the undefined behavior sanitizer. The fix in this patch replaces
this with `strcat`.
Change-Id: I1a0c50c9022adc841e175aad0fe2247bfcb29d71
This commit adds support for vector unit-stride segment store operations
for RISC-V (vssegXeXX). This implementation is based in two types of
microops:
- VsSegIntrlv microops that properly interleave source registers into
structs.
- VsSeg microops that store data in memory as contiguous structs of
several fields.
Change-Id: Id80dd4e781743a60eb76c18b6a28061f8e9f723d
Gem5 issue: https://github.com/gem5/gem5/issues/382
Implement several features new in ROCm 6.0 and features required for
future devices. Includes the following:
- Support for multiple command processors
- Improve handling of unknown register addresses
- Use AddrRange for MMIO address regions
- Handle GART writes through SDMA copy
- Implement PCIe indirect reads and writes
- Improve PM4 write to check dword count
- Implement common MI300X instruction
This update modifies the test configuration to specify the versions of
resources used, rather than automatically using the latest versions.
Previously, if a resource was updated for a change, it could potentially
cause tests to fail if those tests were incompatible with the new
version of the resource.
Now, with this change, tests are tied to specific versions of resources,
ensuring that any updates to resources will require corresponding
updates to the tests to maintain compatibility.
Change-Id: I9633b1749f6c6c82af6aa6697b7e7656020f62fa
Currently gem5 assumes that there is only one command processor (CP)
which contains the PM4 packet processor. Some GPU devices have multiple
CPs which the driver tests individually during POST if they are used or
not. Therefore, these additional CPs need to be supported.
This commit allows for multiple PM4 packet processors which represent
multiple CPs. Each of these processors will have its own independent
MMIO address range. To more easily support ranges, the MMIO addresses
now use AddrRange to index a PM4 packet processor instead of the
hard-coded constexpr MMIO start and size pairs.
By default only one PM4 packet processor is created, meaning the
functionality of the simulation is unchanged for devices currently
supported in gem5.
Change-Id: I977f4fd3a169ef4a78671a4fb58c8ea0e19bf52c
PCIe can read/write to any 32-bit address using the PCI index/index2
registers as an address and then reading/writing the corresponding
data/data2 register.
This commit adds this functionality and removes one magic value being
written to support GPU POST. This feature is disabled for Vega10 which
relies on an MMIO trace for too many values to implement in the MMIO
interface.
Change-Id: Iacfdd1294a7652fc3e60304b57df536d318c847b
The SRBM write packets where previously not required. This commit
implements SRBM writes to set a register by using the new setRegVal
interface. SRBM writes seem to be used for SRIOV enabled devices.
Change-Id: I202653d339e882e8de59d69a995f65332b2dfb8c
