qemu/target
Peter Maydell efbe180ad2 target/arm: Add new MMU indexes for AArch32 Secure PL1&0
Our current usage of MMU indexes when EL3 is AArch32 is confused.
Architecturally, when EL3 is AArch32, all Secure code runs under the
Secure PL1&0 translation regime:
 * code at EL3, which might be Mon, or SVC, or any of the
   other privileged modes (PL1)
 * code at EL0 (Secure PL0)

This is different from when EL3 is AArch64, in which case EL3 is its
own translation regime, and EL1 and EL0 (whether AArch32 or AArch64)
have their own regime.

We claimed to be mapping Secure PL1 to our ARMMMUIdx_EL3, but didn't
do anything special about Secure PL0, which meant it used the same
ARMMMUIdx_EL10_0 that NonSecure PL0 does.  This resulted in a bug
where arm_sctlr() incorrectly picked the NonSecure SCTLR as the
controlling register when in Secure PL0, which meant we were
spuriously generating alignment faults because we were looking at the
wrong SCTLR control bits.

The use of ARMMMUIdx_EL3 for Secure PL1 also resulted in the bug that
we wouldn't honour the PAN bit for Secure PL1, because there's no
equivalent _PAN mmu index for it.

Fix this by adding two new MMU indexes:
 * ARMMMUIdx_E30_0 is for Secure PL0
 * ARMMMUIdx_E30_3_PAN is for Secure PL1 when PAN is enabled
The existing ARMMMUIdx_E3 is used to mean "Secure PL1 without PAN"
(and would be named ARMMMUIdx_E30_3 in an AArch32-centric scheme).

These extra two indexes bring us up to the maximum of 16 that the
core code can currently support.

This commit:
 * adds the new MMU index handling to the various places
   where we deal in MMU index values
 * adds assertions that we aren't AArch32 EL3 in a couple of
   places that currently use the E10 indexes, to document why
   they don't also need to handle the E30 indexes
 * documents in a comment why regime_has_2_ranges() doesn't need
   updating

Notes for backporting: this commit depends on the preceding revert of
4c2c04746932; that revert and this commit should probably be
backported to everywhere that we originally backported 4c2c047469.

Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2326
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2588
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241101142845.1712482-3-peter.maydell@linaro.org
2024-11-05 10:09:58 +00:00
..
alpha target/alpha: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:56 +00:00
arm target/arm: Add new MMU indexes for AArch32 Secure PL1&0 2024-11-05 10:09:58 +00:00
avr target/avr: Use explicit little-endian LD/ST API 2024-10-15 12:13:59 -03:00
hexagon target/hexagon: Use explicit little-endian LD/ST API 2024-10-15 11:55:09 -03:00
hppa target/hppa: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:54 +00:00
i386 target/i386: Set 2-NaN propagation rule explicitly 2024-11-05 10:09:56 +00:00
loongarch target/loongarch: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:54 +00:00
m68k target/m68k: Initialize float_status fields in gdb set/get functions 2024-11-05 10:09:54 +00:00
microblaze target/microblaze: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:57 +00:00
mips target/mips: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:53 +00:00
openrisc target/openrisc: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:57 +00:00
ppc target/ppc: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:54 +00:00
riscv target/riscv: Fix vcompress with rvv_ta_all_1s 2024-10-31 13:51:24 +10:00
rx target/rx: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:57 +00:00
s390x target/s390x: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:54 +00:00
sh4
sparc target/sparc: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:55 +00:00
tricore target/tricore: Use tcg_constant_tl() instead of tcg_gen_movi_tl() 2024-10-15 12:13:59 -03:00
xtensa target/xtensa: Explicitly set 2-NaN propagation rule 2024-11-05 10:09:55 +00:00
Kconfig
meson.build