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>
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>
The GITS_CTLR.quiescent bit is used by priviledged sw to check when the
ITS has finished draining its state (all pending translations/table
walks have ended) once it has been disabled (by setting the
GITS_CTLR.enable bit to 0).
This patch is modelling this behaviour by
* Changing the reset state to enable=0, quiescent=1
* Making the GITS_CTLR.quiescent bit RO
* Updating the bit once a new translation/command is being processed
(quiescent=0) and when there are no pending translation/commands
(quiescent=1)
Change-Id: I7cfe94b25d603400364b1cdfc2d2397acf5dfad8
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/+/20257
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The PCI host has an interrupt-map property which only works for a fixed
setup of parent/child interrupt/address cells, which currently overlaps
with GICv2.
We want to make this flexible, so that the interrupt-map doesn't break
if we change the interrupt/address-cells value, and the patch is aiming
in that direction. This is also needed for GICv3 DTB autogeneration,
since it is using different values than GICv2.
Change-Id: If1c661ddcbc0c277c9d6b0e44a0fd3fe2427618c
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/+/20052
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In the current SMMUv3 model, multiple micro/mainTLB are present at the
device interface (SMMUv3SlaveInterface), caching translations specific
to a device.
Those distributed TLBs are checked for a translation before checking for
centralized TLBs (shared by devices), like the configuration cache, walk
cache etc. This means that if a hit in these TLBs occurs, there won't
be a need to enter configuration stage (which is where the STE and CD
are retrieved). So if we invalidate a cached configuration (in
ConfigCache), we need to invalidate those interface TLB entries as well,
otherwise in theory we will keep the same translation even after a
change in configuration tables.
Change-Id: I4aa36ba8392a530267517bef7562318b282bee25
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Michiel van Tol <michiel.vantol@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19813
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is rewriting the SMMUv3::processCommand method for the
following reasons:
* Command names were not matching spec
* Command encoding/opcode was wrong
The patch is not adding any new command: there is still a subset of
unimplemented commands; those are:
* CMD_TLBI_EL3_ALL
* CMD_TLBI_EL3_VA
* CMD_TLBI_EL2_ALL
* CMD_TLBI_EL2_VA
* CMD_TLBI_EL2_VAA
* CMD_TLBI_EL2_ASID
which require StreamWorld support, and
* CMD_ATC_INV
* CMD_PRI_RESP
* CMD_RESUME
* CMD_STALL_TERM
which require in sequence: ATS, PRI, Stall Model support
Change-Id: Ia2dd47b5588738402d9584a00cfc88c94c253ad0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Michiel van Tol <michiel.vantol@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19668
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
SMMU circular queues have a wrap bit which is used in order to
distinguish between an empty queue and a full queue.
According to SMMUv3 spec:
Each index has a wrap flag, represented by the next higher bit adjacent
to the index value contained in PROD and CONS. This bit must toggle each
time the index wraps off the high end and back onto the low end of the
buffer. It is the responsibility of the owner of each index, producer or
consumer, to toggle this bit when the owner updates the index after
wrapping. It is intended that software reads the register, increments or
wraps the index (toggling wrap when required) and writes back both wrap
and index fields at the same time.
Change-Id: Idfeb397141f3627c2878caaeaa2625fadf671d2a
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Michiel Van Tol <michiel.vantol@arm.com>
Reviewed-by: Adrian Herrera <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19311
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ciro Santilli <ciro.santilli@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
The patch is aiming to be spec compliant when it comes to setup
the SMMU command queue (while CR0.CMDQEN = 0), in the following ways:
* Writes to CMDQ_CONS (read index) are allowed during initialization
* Writes to CMDQ_BASE (cmdq pointer) are allowed during initialization
According to spec,
If they happen when the command queue is in fuction (CR0.CMDQEN = 1),
behaviour is constrained unpredictable, with the following options
1) The write is ignored
2) The register takes the value and it is unpredictable whether it
affects the SMMU command queue internal state.
In the model/patch we go for option 1.
Change-Id: I1c55bc571a8b3a1c0b0a525e429ab7b1480544ff
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Michiel Van Tol <michiel.vantol@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/19633
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This is an implementation of the SMMUv3 architecture.
What can it do?
- Single-stage and nested translation with 4k or 64k granule. 16k would
be straightforward to add.
- Large pages are supported.
- Works with any gem5 device as long as it is issuing packets with a
valid (Sub)StreamId
What it can't do?
- Fragment stage 1 page when the underlying stage 2 page is smaller. S1
page size > S2 page size is not supported
- Invalidations take zero time. This wouldn't be hard to fix.
- Checkpointing is not supported
- Stall/resume for faulting transactions is not supported
Additional contributors:
- Michiel W. van Tol <Michiel.VanTol@arm.com>
- Giacomo Travaglini <giacomo.travaglini@arm.com>
Change-Id: Ibc606fccd9199b2c1ba739c6335c846ffaa4d564
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/+/19008
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch introduces the GICv3 ITS module, which is in charge of
translating MSIs into physical (GICv3) and virtual (GICv4) LPIs. The
patch is only GICv3 compliant, which means that there is no direct
virtual LPI injection (this also means V* commands are unimplemented)
Other missing features are:
* No 2level ITS tables (only flat table supported)
* Command errors: when there is an error in the ITS, it is
IMPLEMENTATION DEFINED on how the ITS behaves. There are three possible
scenarios (see GICv3 TRM) and this implementation only supports one of
these (which is, aborting the command and jumping to the next one).
Furter patches could make it possible to select different reactions
* Invalidation commands (INV, INVALL) are only doing the memory table
walks, assuming the current Gicv3Redistributor is not caching any
configuration table entry.
Change-Id: If4ae9267ac1de7b20a04986a2af3ca3109743211
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/+/18601
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is adding a StreamID tag to any DMA Packet. StreamIDs are
tags which are used by IOMMUs to distinguish between different
devices/functions.
For PCI devices for example, the RID (Pci Bus number, Pci Device
number, Pci Function number) could be stored in the Packet streamID
field.
For the DmaDevice base class, a simple pair of (Sub)StreamIDs has been
provided. This is basically attaching a fixed (decided at python config
time) streamID per device. If a derived device wants to implement a
more elaborate packet tagger (for example if it wants to have more than
one streamID), it needs to pass a different StreamID and SubstreamID to
the DmaPort interface (like dmaAction).
Change-Id: Ia17cf00437f7d3eb79211c1374134b174f90de59
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/+/16749
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
