The previous implementation used the physical memory view when reporting
memory back to GDB. This circumvents MMUs and caches, and leads to wrong
backtraces at the least.
Current architectures support EL3, EL2, and EL1/EL0, and the Iris
interface presents a Msn that corresponds to that (`0x10ff`), see
table "Canonical memory space numbers" in the Iris user guide.
As GDB expects the view of the processor when querying memory (e.g. for
backtraces), this will allow proper backtraces.
Not sure if there is an implicit way of expressing memory attributes
(like in Lauterbach with the access modifiers before address
specifications), or if there is a need to implement special monitor
commands. But for the common use, using `CurrentMsn` should be the
correct choice.
Change-Id: Ibd14c1f94163105539a7fb9132550fe713b5c295
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61951
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Current WFI implementation always put the CPU to sleep even if there's
an pending interrupt. This might cause issue because an interrupt might
happen just before the WFI is executed, and there might not be any
further interrupts to wake the CPU up, so the CPU sleeps indefinitely.
In this CL, we ensure the CPU sleeps only if there's no pending
interrupt at all, regardless whether the interrupt is masked or not. We
intentionally check for masked interrupt as well because a masked
interrupt is also able to wake the CPU up if it occurs after WFI. This
will make the behavior consistent no matter the interrupt comes before
or after WFI.
Change-Id: I74dbc01fed52652101675f1ae8e481b77c932088
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62251
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This implements flattening in the x86 integer and floating point
RegClass-es, as well as adding regName functions for each. These came
from the X86StaticInst::printReg function, and the flattening functions
in the X86ISA::ISA class.
Change-Id: If026e3b44aa64441222451d91e99778f6054d9f0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51228
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Most of the invalidation methods in the TLB class are
doing the same thing: looping over all entries, checking if
the entry matches a certain criteria, and invalidating it
in case it does.
The only specific bit is the matching function, therefore
we add a virtual TLBIOp::match method which allows us
to specialize different TLBIs and to provide a single
flush method in the TLB class
Change-Id: I0672ff958742ac7ebff8d30218f75127343f1a58
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61753
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
The method is no longer calling the lookup method which
had been complicated by the introduction of partial translations.
(which is now called during address translation only)
The lookup method is iterating over all TLB Entries until a non
partial translation is found. Using lookup in flushMva makes it
O(n^2). With this patch we iterate over the TLB entries only once
(making flushMva O(n))
Change-Id: I8f2ae56192812cee231baf6943068abea4d7ef91
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61752
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Fixing invalidation behaviour for the following stage 2 TLB maintainance
instructions
MISCREG_TLBI_IPAS2E1_Xt
MISCREG_TLBI_IPAS2LE1_X
MISCREG_TLBI_IPAS2E1_Xt
MISCREG_TLBI_IPAS2LE1_Xt
1) Do nothing if EL2 is not enabled in the current security state
2) If we are in secure state, the 63 bit of the Xt register selects
the security domain (s/ns) of the invalidated entries
Change-Id: I4573ed60ce619bcefd9cb05f00c5d3fcfa8d3199
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61751
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Replace the two constructors with one that takes the truly mandantory
parameters, and then a function to derive a new RegClass with some sort
of adjustment, currently by adding custom ops, or setting a non-standard
register size.
Because the constructor and the modifier function are constexpr, they
should fold away and not actually create extra temporary copies of the
RegClass in the modifier functions.
Change-Id: I8acb755eb28fc8474ec453c51ad205a52eed9a8e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50249
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The following AArch64 CMOs were flagged as warnNotFail even
if they are actually implemented and there is no reason
for them to fail:
MISCREG_DC_IVAC_Xt
MISCREG_DC_ZVA_Xt
MISCREG_DC_CVAC_Xt
MISCREG_DC_CVAU_Xt
MISCREG_DC_CIVAC_Xt
This is likely coming from AArch32 (those CMOs are unimplemented in
AArch32).
Please note: this patch is not changing anything behaviorally; the
warnOnFail flag is not considered in AArch64 unless the unimplemented
flag is also set (and this was not the case for those CMOs)
Change-Id: I40396016703b9eb48f69b0eb710d077f8c2b146b
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61685
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
These instructions are supposed to be read/writing special shader
hardware registers. Currently they are getting/setting to an SGPR. This
results in getting incorrect registers at best and clobbering an SGPR
being used by an application at worst. Furthermore, some registers need
to be set in the shader and the application will never (can never) set
them.
This patch overhauls the getreg/setreg instructions to use different
storage in the shader. The values will be updated either via setreg from
an application (e.g., mode register) or set by a PM4 MAP_PROCESS.
Change-Id: Ie5e5d552bd04dc47f5b35b5ee40a569ae345abac
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61655
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Here the mask should not be inverted. We also need to shift by the
offset to remove the padding as the consumer of the value expects the
offset to be removed.
This can be easily tested by running a GPU kernel with __shared__
variables. This will generate the following assembly:
s_getreg_b32 s6, hwreg(HW_REG_SH_MEM_BASES, 16, 16)
The current implementation returns the lower 16 bits (private memory
aperture) while the correct behavior is the uppter 16 bits (shared/LDS
memory aperture).
Change-Id: Iea8f0adceeadb24cdcf46ef4183fcaa8262ab9e7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61654
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
This instruction appears to be the only VOP1 instruction that has a
scalar destination using VDST as the destination register number.
However, since VDST is only 8 bits it cannot encode all possible
registers. Therefore, use the opcode to determine if the destination is
a scalar or vector destination.
This issue manifests as a VGPR dest being out of range for a kernel
where the number of SGPRs is more than the number of VGPRs and the
intended SGPR dest is larger than the count of VGPRs
Change-Id: I95a7de1ddb97f7171f48331fed36aef776fa0cb4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61649
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These VHE flags are not needed anymore.
They were used to trap EL2 access to VHE only registers (like CPACR_EL12)
when VHE was disabled (hcr.e2h = 0)
With the new faulting logic, we can just introduce VHE specific
callbacks checking for the hcr.e2h bitfield and returning an undefined
instruction if VHE is disabled.
In this way we don't have to add VHE only bits to every system register
Change-Id: I07bf9a9adc7a089bd45e718fb06d88488a2b7ed5
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61678
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is adding per-EL read/write callbacks to the MiscRegLUTEntry
class. The goal is to merge access permission and trapping logic into
these unified callbacks
As of now the default callbacks are simply reimplementing the access
permission code, checking for MiscRegLUTEntry flags. This is the default
behaviour for all registers.
Trapping code (from MiscRegOp64::trap) will be moved with a later patch
Change-Id: Ib4bb1b5d95319548de5e77e00258fd65c11d88d7
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61675
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
The iss field is only used when the MSR/MRS instruction
gets trapped. Rather than generating it at decode time,
we generate the value within the trap method instead
This avoids the confusion of having a MSR/MRS register
instruction storing an immediate field
Later patches will change this even further by generating the
iss field on the fly ONLY if the instruction gets trapped
Change-Id: I97fdcf54d9643ea79a1f9d052073320ee68109fd
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61670
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
First, this CL modifies the implementation of WFI so it actually put the
calling CPU into sleep.
This CL also adds an id in the IRQ table to represent NMI. This is
because the wakeup path is only implemented on cpu's postInterrupt
function, and it expects an int_num.
We still keep the MISCREG for nmie and nmip instead of merging them into
other ip/ie as that will give the user ability to get/set the nmi
status, which is pretty dangerous.
Change-Id: Idf8a5748990efa20aa9372efa97d3bed2aac82d9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61511
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Vega adds three new VOP2 instructions that may use VOP3 encoding that
are not part of the GCN3 ISA: v_add_u32, v_sub_u32, v_subrev_u32. This
changeset implements those three new instructions to fix errors related
to "invalid encoding" when those instructions are seen.
Tested using srad from Rodinia 3.0 HIP port which compiles a v_add_u32
instruction with VOP3 encoding.
Change-Id: I409a9f72f5c37895c3a0ab7ceb14a4dd121874a4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61330
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
