#
14221:2954f631ee64 |
|
20-Aug-2019 |
Adrian Herrera <adrian.herrera@arm.com> |
dev-arm: Implement invalidateVA/VAA in SMMUv3 WalkCache
This patch implements VA/VAA invalidations in the SMMUv3 model.
As per SMMUv3.0 spec, if leaf bit is specified in the invalidation command, only leaf entries within the walk cache need to be invalidated, otherwise entries with intermediate translations are also invalidated.
Change-Id: I0eb1e1f1d8c00671a3c23d2a8fb756f2020d8d46 Reviewed-by: Michiel van Tol <michiel.vantol@arm.com> Reviewed-by: Marc Mari Barcelo <marc.maribarcelo@arm.com> Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20258 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: kokoro <noreply+kokoro@google.com>
|
#
14132:d6093eeca3af |
|
25-Jul-2019 |
Giacomo Travaglini <giacomo.travaglini@arm.com> |
dev-arm: Perform SMMUv3 CFG Invalidation at device interface
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>
|