arch-arm: Fix physmem NS attribute in VMSAv8-32 descriptors
authorGiacomo Travaglini <giacomo.travaglini@arm.com>
Wed, 12 Aug 2020 11:14:06 +0000 (12:14 +0100)
committerGiacomo Travaglini <giacomo.travaglini@arm.com>
Fri, 14 Aug 2020 13:07:41 +0000 (13:07 +0000)
commit0c28712f51f5b0748c3afd5b287969ceb615ea8d
tree3ee40a157f99c6c27541d134ba4bc42d3f49bf6b
parentd3ec83ae3ec6d2908f260398150f64068c4ad802
arch-arm: Fix physmem NS attribute in VMSAv8-32 descriptors

The NS field in PTEs descriptors is tagging Secure/Non-secure physical
memory (pages). This field is relevant in Secure state only:

While in Secure state, software can access both the Secure and
Non-secure physical address spaces, software in Non-secure state can
only access Non-secure memory; the NS bit is hence discarded/treated as
1.

This patch is aligning VMSAv8-32 with VMSAv8-64, which is tagging the
pointed memory as Non-secure in case of a Non-secure lookup.

The old behaviour was probably not leading to incorrect execution:
once a translation completes, the security flag in the memory request
is chcked against the security state of the cpu (and not only relying
on the NS bit in the TLB entry)

if (isSecure && !te->ns) {
    req->setFlags(Request::SECURE);
}

so we were already forbidding secure accesses from non secure world
if NS = 0.

It is however misleading in the debug logs to see tlb entries with
NSTID = 1 and NS = 0.

Change-Id: I1f964069f88c33fb14362dd4101cb22538907226
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32638
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
src/arch/arm/table_walker.hh