Previous mapping was wrong because it was checking which security bits
it was accessing by using the inSecureState() function, whereas it
should have used the isSecureBelowEL3(). This patch is not making the
sostitution since it is optimizing the mapping furthermore by avoiding
updating both IGRPEN1_EL1 and IGRPEN1_EL3 on writes. The IGRPEN1_EL1
register is used as a storage, and any reads/writes to IGRPEN1_EL3 is
routed to that register.
Change-Id: Id318ec44e19d4f844e4e3410d74d0c4f89810811
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20632
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The SVE patches made registers longer by increasing NumVecElemPerVecReg,
but the GDB XML was not updated to account for that, and as a result GDB
connections were failing with:
Remote 'g' packet reply is too long
This commit introduces NumVecElemPerSimdVecReg which counts only the SIMD
register sizes to get it back working. SVE GDB support is not added here.
Change-Id: I4191b9f1999ae02b0308863db4cc9b5b16a27d6d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20468
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The GICv3 update methods are method which are invoked anytime the model
needs to evaluate a change in its state, which most of the time means
managing the state of an interrupt (forwarding it to a PE, deasserting
it, etc).
The way it is currently done is a little bit obscure and doesn't
handle correctly IRQ prioritization.
Example:
An IRQ which is handled by the redistributor (PPI or LPI) was not
competing with any pending interrupts coming from the distributor (SPIs)
once raised by a peripheral.
Also the way the pending state of an interrupt was removed at the
cpu interface level wasn't happening in place where this was actually
happening (E.g. when activating it), but happened with a weird
fullUpdate semantic, where if there was a pending interrupt in a
cpu interface, all cpu interfaces had their pending interrupt (if any)
been disabled.
With this patch, state update always starts at the distributor, and
it goes down until the cpu interface where a Gicv3CPUInterface::update
method selects the winning interrupt coming from distributor/redistributor
to be forwarded to the PE.
Change-Id: I1c517cbc4bf107cc2d7ae7beb2692e3cf5187a40
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20614
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The patch is fixing the following aspects of SGIs
* The conditons over which an SGI can be forwarded to a PE
* SGIs in AArch32 (see below)
It is in fact refactoring SGI generation under a common method in the
cpu interface. It is abandoning the implicit fallthrough mechanism not
only for cosmetic reasons, but also because checking "misc_reg ==" was
only working if the register was an AArch64 one (e.g.
MISCREG_ICC_SGI0R_EL1) and not the AArch32 counterpart (MISCREG_SGI0R).
Change-Id: I6fedfb80388666f4f1d20f6abef378a9f093aa83
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20610
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The current default base address for GICv3 ITS stated in RealView is
0x2c120000. The redistributors base address is 0x2c010000; each
instantiated core has an associated redistributor with memory region
size 0x40000 (with GICv4 extension, enabled by default). With 8 cores,
the redistributor range spans to 0x2c210000, creating a conflict with
the ITS address space.
This patch changes the ITS base address to 0x2e010000 which guarantees
no overlapping with the redistributor.
Change-Id: I7dc1af9e69ac037f85ae96f0985554f1fb8372a0
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20608
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The SMMUv3SlaveInterface is using the xlateSlotsRemaining to model a
limit on the number of translation requests it can receive from the
master device.
Patch
https://gem5-review.googlesource.com/c/public/gem5/+/19308/2
moved the resource acquire/release inside the SMMUTranslationProcess
constructor/destructor, for the sake of having a unique place for
calling the signalDrainDone.
While this is convenient, it breaks the original implementation,
which was freeing resources AFTER a translation has completed, but
BEFORE the final memory access (with the translated PA) is performed.
In other words the xlateSlotsRemaining is only modelling translation
slots and should be release once the PA gets produced.
The patch fixes this mismatch by restoring the resource release in
the right place (while keeping the acquire in the constructor)
and by adding a pendingMemAccess counter, which is keeping track
of a complete device memory request (translation + final access)
and will be used by the draining logic
Change-Id: I708fe2d0b6c96ed46f3f4f9a0512f8c1cc43a56c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Adrian Herrera <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20260
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Non-temporal quadword/double-quadword move instructions.
This change ignores the non-temporal hint and instructions are
implemented to send cacheable request to memory.
This would have some "performance" impact (i.e. having some cache
pollution) to get better "correctness" in behavior.
Change-Id: I2052ac0970f61a54bafb7332762debcb7103202d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20288
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
data_write_req byteEnable which is used in ARM SVE partial writes was not
being zeroed between writes.
As a result, non-SVE memory write instructions such as STP that followed
SVE memory write instructions could still have the write mask active.
This could lead to wrong simulation behaviour, and to an assertion failure:
src/mem/packet.hh:1211: void Packet::writeData(uint8_t*) const: Assertion
`req->getByteEnable().size() == getSize()' failed. '`
Change-Id: I74b5a82675e9923b0ffdf2c1dd9afb00c91cb204
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20448
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When creating a base class which needs to be a SimObject, it's
necessary to decide ahead of time whether to use PioDevice or
BasicPioDevice in the hierarchy because they inherit from SimObject. If
they were added into the hierarchy later, then the original class would
inherit from SimObject, as would PioDevice. That would create a diamond
inheritance structure which would require virtual inheritance, and
that's a can of worms we'd rather not get into.
A big part of the PioPort mechanism is the PioPort itself which holds
a pointer to its parent device and delegates reads/writes to it. It
does that with a PioDevice pointer, and PioDevice declares virtual
functions for all the callbacks the port can call into.
Instead of that, this change templatizes PioPort based on the class of
the device that holds it. That will let you use a PioPort on *any*
class, as long as it has the methods PioPort depends on. That removes
the need to create an inheritance diamond to add a PioPort down the
line since PioDevice is no longer strictly required.
The PioDevice and BasicPioDevice classes are still around since they
still provide some additional functionality and there are existing
classes which depend on them.
Change-Id: I753afc1e0fa54b91217d54c1f8743c150537e960
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20568
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
To ensure that enqueuer observes the practical availability. We
check the message buffer queue size at the start of the cycle.
We also add the size of the stall queue to consider the total
queue size. However, messages can be moved from regular queue
to stall map. This leads to messages being considered twice leading
to false flow control. This patch fixes it by storing the stall map
size at the beginning of the cycle and considering it for checking
availability.
Change-Id: I6ea94f34fe5279b91f74e106d43263e55ec4bf06
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20389
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
When using the HDF5 stats backend, we currently pass the filename from
the command line straight to the HDF5 library. This behaviour is
different from the expected behaviour when using plain text stat files
where relative paths are resolved relative to simout. This change adds
support for resolving hdf5 paths relative to simout.
Change-Id: I09cb0b7468735e697125eda7f04c5a85725ca8d0
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20508
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
