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
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
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>
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
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
Change-Id: I5c5c7925fa7f78a7b5e2adc209187deff53ac039
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
Change-Id: I3b02c618c369ef56d32a0b04e0b13eacc9fb4977
Modify the FDArray::unserialize function to perform a checkPathRedirect
if a Process pointer is passed in.
Currently when restoring a checkpoint, it doesn't perform
checkPathRedirect for files that were opened during checkpointing. This
patch adds a checkPathRedirect in the FDArray::unserialize to redirect
app path for restoring checkpoints.
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
Change-Id: Ice97c1fc4cccbfb6824e313ebecde00f134ebf9c
sim/fd_array.hh:
Add "class Process;" to forward declare Process for unserialize
function to pass in a Process object pointer.
Fix the styling issue with include files.
sim/fd_array.cc"
Add comments.
Change-Id: Ifb21eb1c7bad119028b8fd8e610a125100fde696
When reset a port, we don't want to trigger a onChange().
Offer an option to bypass it and update state only.
Change-Id: Ia53b7a76d2a320ea67101096cdbfe2eafaf440d2
This commit fixes a crash in the syscall emulation of the chdir(2)
syscall, implemented by chdirFunc() in src/sim/syscall_emul.cc,
when passed a nonexistent directory. The buggy code did not check
the return value of realpath().
This patch adds code to check the return value of realpath(), and
if it is NULL (i.e., there was an error with the requested directory
to change to), propagates the error in `errno` to the application.
GitHub issue: https://github.com/gem5/gem5/issues/276
Change-Id: I8a576f60fe3687f320d0cfc28e9d3a6b477d7054
This patch fixes the buggy special path comparisons in
src/kern/linux/linux.cc Linux::openSpecialFile(), which only checked
for equality of path prefixes, but not equality of the paths
themselves. This patch replaces those buggy comparisons with
regular std::string::operator== string equality comparisons.
GitHub issue: https://github.com/gem5/gem5/issues/269
Change-Id: I216ff8019b9a6a3e87e364c2e197d9b991959ec1
Currently the MOESI_AMD_Base-directory transition for system level
atomics sends the response message before the atomic is performed. This
was likely done because atomics are supposed to return the value of the
data *before* the atomic is performed and by simply ordering the actions
this way that was taken care of.
With the new atomic log feature, the atomic values are pulled from the
log by the coalescer on the return path. Therefore, these actions can be
reordered. However, it is now necessary that the atomics be performed
before sending the response so that the log is populated and copied by
the response action. This should fix#253 .
Change-Id: Ie7e178f93990975367de2cc3e89e5ef9c9069241
The RM field of ModRM was printed as Reg field for several instructions.
For reference, this change fixes typos introduced by [1].
[1] https://gem5-review.googlesource.com/c/public/gem5/+/40339
Change-Id: I41eb58e6a70845c4ddd6774ccba81b8069888be5
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
Starting with gfx900 (Vega) the LDS and scratch apertures can be queried
using a new s_getreg_b32 instruction. If the instruction is called with
the SH_MEM_BASES argument it returns the upper 16 bits of a 64 bit
address for the LDS and scratch apertures. The current addresses cannot
be encoded in this register, so that addresses are changed to have the
lower 48 bits be all zeros in addition to writing the bases register.
Change-Id: If20f262b2685d248afe31aa3ebb274e4f0fc0772
Augmenting the DataBlock class with a change log structure to record the
effects of atomic operations on a data block and service these changes
if the atomic operations require return values.
Although the operations are atomic, the coalescer need not send unique
memory requests for each operation. Atomic operations within a wavefront
to the same address are now coalesced into a single memory request. The
response of this request carries all the necessary information to
provide the requesting lanes unique values as a result of their
individual atomic operations. This helps reduce contention for request
and response queues in simulation.
Previously, only the final value of the datablock after all atomic ops
to the same address was visible to the requesting waves. This change
corrects this behavior by allowing each wave to see the effect of this
individual atomic op is a return value is necessary.
This patch allows a local JSON file to specify a local path in the JSON
object of a Resource, through the "url" field.
Local paths can be entered with the prefix "file:" in the "url" field.
If the local path exists, then the Resource from there is copied into
the resource directory defined in the
function earlier.
This behavior is the same as using specific Resource classes (ex.
BinaryResource) and passing a local_path into the function.
But, the above class does not allow simultaneous creation of local
Resources and Workloads of those local Resources.
With this patch, someone can use a local JSON, specify the location of
local Resources and create a Workload from those Resources and test both
together.
This patch allows a local JSON file to specify a local path
in the JSON object of a Resource, through the "url" field.
Local paths can be entered with the prefix "file:" in "url".
All File URI scheme formats are supported.
This behavior is the same as using specific Resource classes
(ex. BinaryResource) and passing a local_path into the function.
But, the above infrastructure does not allow simultaneous
creation of Resources and Workloads of those Resources.
With this patch, someone can use a local JSON, specify the location
of local Resources and create a Workload from those Resources and
test both together.
Also, this patch adds pyunit tests to check the functionality
of the function used to convert the "url" field into a path.
Change-Id: I1fa3ce33a9870528efd7751d7ca24c27baf36ad4
DCT must be disabled when handling a ReadUnique where the copy need to
be upgraded.
Previously we were just asserting as it was assumed DCT is only enabled
for HNFs (which can "auto-upgrade"). However DCT may also be enabled for
intermediated levels of distributed shared caches above the HNFs.
Currently we generate these stats for all defined Events in the
protocol, which may generate too many stats that are never used. Though
these don't appear in the stats.txt file, they unnecessarily increases
simulation startup time and memory footprint.
This patch limits those stats to events with the "in_trans" and/or
"out_trans" properties. SLICC compiler then checks which combinations of
event+state are possible when generating the stats.
Also the possible level of detail for inTransLatHist was reduced.
Only the number of transactions for each event+initial+final state
combinations is now accounted. Latency histograms are only defined per
event type (similarly to outTransLatHist). This significantly reduces
the final file size for generated stats.
Flat scratch instructions (aka private) are the 3rd and final segment of
flat instructions in gfx9 (Vega) and beyond. These are used for things
like spills/fills and thread local storage. This commit enables two
forms of flat scratch instructions: (1) flat_load/flat_store
instructions where the memory address resolves to private memory and (2)
the new scratch_load/scratch_store instructions in Vega. The first are
similar to older generation ISAs where the aperture is unknown until
address translation. The second are instructions guaranteed to go to
private memory.
Since these are very similar to flat global instructions there are
minimal changes needed:
- Ensure a flat instruction is either regular flat, global, XOR scratch
- Rename the global op_encoding methods to GlobalScratch to indicate
they are for both and are intentionally used.
- Flat instructions in segment 1 output scratch_ in the disassembly
- Flat instruction executed as private use similar mem helpers as global
- Flat scratch cannot be an atomic
This was tested using a modified version of the 'square' application:
template <typename T>
__global__ void
scratch_square(T *C_d, T *A_d, size_t N)
{
size_t offset = (blockIdx.x * blockDim.x + threadIdx.x);
size_t stride = blockDim.x * gridDim.x ;
volatile int foo; // Volatile ensures scratch / unoptimized code
for (size_t i=offset; i<N; i+=stride) {
foo = A_d[i];
C_d[i] = foo * foo;
}
}
Change-Id: Icc91a7f67836fa3e759fefe7c1c3f6851528ae7d
According to the ABI documentation from LLVM, the *low* register of flat
scratch (maxSGPR - 4) is the offset and the high register (maxSGPR - 3)
is size. These are currently backwards, resulting in some gnarly
addresses being generated leading to page fault and/or incorrect data.
This commit fixes this by setting the order correctly.
Change-Id: I0b1d077c49c0ee2a4e59b0f6d85cdb8f17f9be61
Flat instructions may access memory locations in LDS (scratchpad) and
global (VRAM/framebuffer) and therefore increment both counters when
dispatched. Once the aperture is known, we decrement the counters of the
aperture that was *not* used. This is done incorrectly for scratch /
private flat instruction. Private memory is global and therefore local
memory counters should be decremented.
This commit fixes the counters by changing the global decrements to
local decrements.
Change-Id: I25890446908df72e5469e9dbaba6c984955196cf
The functional HSA signal read was a hack left in the gpu-compute code.
In full system, this functional read is causing problems occasionally
with the translation not yet being in the page table. The error message
output by gem5 was a fatal message on the readBlob method in port proxy.
Changing this to a timing DMA fixes this problem.
This commit adds the various timing DMA functions to send and receive
response and clean up. A helper method "sendCompletionSignal" is added
to the GPUCommandProcessor because the indentation level was getting too
deep. This change applies only to FS mode. Code for SE mode is
equivalent to what it was before this commit.
Change-Id: I1bfcaa0a52731cdf9532a7fd0eb06ab2f0e09d48
configs,dev-amdgpu: Add PCI express capability info
The ROCm stack requires PCI express atomics. Currently the first PCI
CapabilityPtr does not point to anything, which signals to the OS
(Linux) that this is an early generation PCI device. As PCI express
atomics were introduced later, the CapabilityPtr needs to point to at
least a PCI express capability structure. This capability is defined as
0x10 in Linux. We additionally set the PCI atomic based bits and
implement device specific PCI configuration space reads and writes to
the amdgpu device.
The second commit, output of simulation when loading the amdgpu
driver no longer outputs "PCIE atomics not supported". Further, an
application which uses PCIe atomics (PyTorch with a reduce_sum kernel)
now makes further progress.
First commit is a minor typo fix changing PCI capability struct to
union.
In the RISC-V system, we need to VecClassReg to run RISC-V vector
instruction, and VecElemReg is not applicable because the element length
of vector can be resizable via vset\*vl\* instruction.
The change will seperate the reg_index for VecReg and VecElemReg to
ensure that have the space for VecReg when VecElemReg is not applicable.
