The long/daily tests in "tests/gem5/gem5_library_tests" were running in
both the "testlib-long-tests" and the
"testlib-long-gem5_library_example_tests" job in the Daily tests
Workflow. The running in "testlib-long-tests" is removed in this PR.
This change, https://github.com/gem5/gem5/pull/205, mistakenly allocates
write buffer for clflush instruction when there's a cache miss. However,
clflush in gem5 is not a write instruction. Thus, the cache should
allocate miss buffer in this case.
Via this workflow we now can build and push our docker images to
the GitHub Docker container registry:
26a1ee4e61/.github/workflows/docker-build.yaml
GitHub does not charge for downloads to runners (hosted or self-hosted).
This can therefore save the project money if we download from GitHub's
Docker reigstry over Google Cloud's.
This is a test to ensure this works as intended.
Change-Id: Iccdb1b7a912f1e0a0d82b7f888694958099315b3
The long/daily tests in "tests/gem5/gem5_library_tests" were running in
both the "testlib-long-tests" and the
"testlib-long-gem5_library_example_tests" job in the Daily tests
Workflow. The running in "testlib-long-tests" is removed in this patch.
Change-Id: I1c665529e3dcb594ffb7f6e2224077ae366772d6
When there is race between FwdGetX
and PUTX on owner. Owner in this case hands off
ownership to GetX requestor and PUTX still goes
through. But since owner has changed, state should
go back to M and PUTX is essentially trashed.
An Unblock to the Directory in this case will give an undefined
transition. I have added transitions which indicate that when
an Unblock is served to the Directory, it means that some kind
of ownership transfer has happened while a PUTX/PUTO was in
progress.
Change-Id: I37439b5a363417096030a0875a51c605bd34c127
https://github.com/gem5/gem5/actions/runs/6114221855 failure was due to
to running the actions inside our 22.04-all-dependencies container. This
container does not contain docker. We must therefore run this action
outside of the container. However, due to our policy of checking out the
code within this container, we must split this into two jobs and use the
artifact upload and download to get the resources we want.
Links to #293
After calling m5_dump_reset_stats(0,0) in a test program, some
statistics like
l1_controllers.L1Dcache.m_demand_hits,
l1_controllers.L1Dcache.m_demand_misses,
l1_controllers.L1Dcache.m_demand_accesses
were not getting reset in the newer stat dumps.
This one line patch fixes that. Changes were tested with calling two
m5_dump_reset_stats(0,0) in a row for a system with 1 core, tested on
both SE and FS.
Credits: @MeatBoy106
The x87 FPU tag word (FTW) was not explicitly initialized in
{X86_64,i386}Process::initState(), resulting in holding an initial value
of zero, resulting in an invalid x87 FPU state. This commit initializes
FTW to 0xFFFF, indicating the FPU is empty at program start during
syscall emulation.
The 16-bit FTW register was also incorrectly masked down to 8-bits in
X86ISA::ISA::setMiscRegNoEffect(), leading to an invalid X87 FPU state
that later caused crashes in the X86KvmCPU. This commit corrects the
bitwidth of the mask to 16.
GitHub issue: https://github.com/gem5/gem5/issues/303
A recent PR [1] moved the TraceCPU away from the BaseCPU hierarchy.
While the common etrace_replayer.py has been amended, I missed these
hybrid TLM + TraceCPU example scripts.
[1]: https://github.com/gem5/gem5/pull/302
After calling m5_dump_reset_stats(0,0) in a test program,
some statistics like
l1_controllers.L1Dcache.m_demand_hits,
l1_controllers.L1Dcache.m_demand_misses,
l1_controllers.L1Dcache.m_demand_accesses
were not getting reset in the newer stat dumps.
This one line patch fixes that. Changes were tested with
calling two m5_dump_reset_stats(0,0) in a row for a system
with 1 core, tested on both SE and FS.
Credits to Gabriel Busnot for finding the fix.
Change-Id: I19d75996fa53d31ef20f7b206024fd38dbeac643
A recent PR [1] moved the TraceCPU away from the BaseCPU hierarchy.
While the common etrace_replayer.py has been amended, I missed these
hybrid TLM + TraceCPU example scripts.
[1]: https://github.com/gem5/gem5/pull/302
Change-Id: I7e9bc9a612d2721d72f5881ddb2fb4d9ee011587
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This is used by Pylance IntelliSense to infer gem5 typing.
See "util/gem5-stubgen.py" for generating this directory.
Change-Id: Ie39762c718e5392f6194ff7c8238bd0cd677f486
Python 3's `-P` flag, when set, means `sys.path` is not prepended with
potentially unsafe paths:
https://docs.python.org/3/using/cmdline.html#cmdoption-P
This patch allows gem5 to mimic this. This is necesssary when using
`mypy.stubgen` as it expects the Python Interpreter to have the `-P`
flag.
Change-Id: I456c8001d3ee1e806190dc37142566d50d54cc90
The x87 FPU tag word (FTW) was not explicitly initialized in
{X86_64,i386}Process::initState(), resulting in holding an initial
value of zero, resulting in an invalid x87 FPU state. This commit
initializes FTW to 0xFFFF, indicating the FPU is empty at program
start during syscall emulation.
The 16-bit FTW register was also incorrectly masked down to 8-bits
in X86ISA::ISA::setMiscRegNoEffect(), leading to an invalid X87 FPU
state that later caused crashes in the X86KvmCPU. This commit
corrects the bitwidth of the mask to 16.
GitHub issue: https://github.com/gem5/gem5/issues/303
Change-Id: I97892d707998a87c1ff8546e08c15fede7eed66f
The syscall emulation of newfstatat incorrectly treated the output stat
buffer to be of type `OS::tgt_stat`, not `OS::tgt_stat64`, causing the
invalid output stat buffer in the application to hold invalid data.
This patch fixes the bug by simply substituting the type `OS::tgt_stat`
with `OS::tgt_stat64` in `newstatatFunc()`.
GitHub issue: https://github.com/gem5/gem5/issues/281
The syscall emulation of tgkill contained a simple logic bug (a `||`
instead of a `&&`), causing the signal argument to always be considered
invalid. This patch fixes the bug by simply changing the `||` to a `&&`.
GitHub issue: https://github.com/gem5/gem5/issues/284
If the XSAVE KVM capability is available (KVM_CAP_XSAVE), the X86KvmCPU
will try to set the x87 FPU + SSE state using KVM_SET_XSAVE, which
expects a buffer (struct kvm_xsave) in XSAVE area format (Vol. 1, Sec.
13.4 of Intel x86 SDM). The original implementation of
`X86KvmCPU::updateKvmStateFPUXSave()`, however, improperly sets the
xsave header, which contains a bitmap of state components present in the
xsave area.
This patch defines `XSaveHeader` structure to model the xsave header,
which is expected directly following the legacy FPU region (defined in
the `FXSave` structure) in the xsave area. It then sets two bist in the
xsave header to indicate the presence of x86 FPU and SSE state
components.
GitHub issue: https://github.com/gem5/gem5/issues/296
Changes in the PR:
1. Change the vset\*vl\* instructions to jump/branch family, and
implement the branchTarget.
2. Move the Vl and Vtype from decoder to PCState
3. get VL, VTYPE and VLENB value from PCState
4. Remove vtype checking in construction so that the minor and o3 cpu
and decode the instructions after the vset\*vl\*
Now that the TraceCPU is no longer a BaseCPU we disable CPU switching
functionality. AFAICS from the code, it seems like using m5.switchCpus
was never really working.
The takeOverFrom was described as being used when checkpointing
(which is not really the case). Moreover the icache/dcache
event loops were not checking if the CPU was switched out
so the trace was always been consumed regardless of the BaseCPU
state.
Note: IMHO the only case where you might want to switch between
an execution-driven CPU to the TraceCPU is when you want to
warm your caches before the ROI.
All other cases don't really make sense as with the TraceCPU
there is no architectural state being maintained/updated.
Change-Id: I0611359d2b833e1bc0762be72642df24a7c92b1e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
As we no longer inherit from the BaseCPU, we can't really use
CPU generation methods (like Simulation.setCPUClass) and
cache generation ones (like CacheConfig.config_cache).
This is good news as it allows us to simplify the etrace
script and to remove a dependency with the deprecated-to-be
common library.
Change-Id: Ic89ce2b9d713ee6f6e11bf20c5065426298b3da2
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This is fixing a recently reported issue [1] where it is
not possible to use the TraceCPU to replay elastic traces
It requires some architectural data structures (like ArchMMU,
ArchDecoder...) which are no longer defined in the BaseCPU class at
compilation time. Which Arch version should be used for a class
(TraceCPU) that is supposed to be ISA agnostic ? Does it really make
sense to define them for the TraceCPU? Those classes are not used anyway
during trace replay and their sole purpose would just be to comply to
the BaseCPU interface.
As there is no elegant way to make things work, this patch stops
treating the TraceCPU as a BaseCPU.
While it philosophically makes sense to treat the TraceCPU as a common
CPU (it sort of replays pre-executed instructions), a case can be made
for considering it more like a traffic generator.
[1]: https://github.com/gem5/gem5/issues/301
Change-Id: I7438169e8cc7fb6272731efb336ed2cf271c0844
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The changes includes:
1. Add VL, Vtype and VlenbBits operands
2. Change R/W methods of VL, Vtype and VlenbBits from PCState
Change-Id: I0531ddc14344f2cca94d0e750a3b4291e0227d54
We should not try to check vtype when decoding the instruction.
It should be checked in vset{i}vl{i} since the register can be
modified via vset{i}vl{i}
Change-Id: I403e5c4579bc5b8e6af10f93eac20c14662e4d2d
This adds the setting up of environment variables to the gcn-gpu
Dockerfile from the halofinder Dockerfile in gem5-resources so that we
don't need to use a separate Docker image in the gpu tests.
This reverts commit 0249d47acc,
https://github.com/gem5/gem5/pull/271.
This solution doesn't work. GitHub runners pull the images they need at
the start of job (i.e., all the images they may need for each step).
They then create the containers later, at the step they are needed. This
solution therefore breaks in the case a cleanup happens during the
running of a job. I.e., a `docker system prune` happens after setup,
therefore deleting all the images, then the job tries to use one of the
images during a step.
This crontab solution may work if we can only do it when the runner is
in an idle state. Whether this is possible is unknown.
This reverts commit 0249d47acc,
https://github.com/gem5/gem5/pull/271.
This solution doesn't work. GitHub runners pull the images they need at
the start of job (i.e., all the images they may need for each step).
They then create the containers later, at the step they are needed.
This solution therefore breaks in the case a cleanup happens during the
running of a job. I.e., a `docker system prune` happens after setup,
therefore deleting all the images, then the job tries to use one of the
images during a step.
This crontab solution may work if we can only do it when the runner is
in an idle state. Whether this is possible is unknown.
Change-Id: I7cb5b2d98d596e9380ae1525c7d66ad97af1b59b
