The HSTR_EL2 register is not supposed to have an effect unless EL2 is
enabled in the current security state. We weren't checking for this,
which meant that if the guest set up the HSTR_EL2 register we would
incorrectly trap even for accesses from Secure EL0 and EL1.
Add the missing checks. (Other places where we look at HSTR_EL2
for the not-in-v8A bits TTEE and TJDBX are already checking that
we are in NS EL0 or EL1, so there we alredy know EL2 is enabled.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
target/arm/helper.c | 2 +-
target/arm/op_helper.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 6f6772d8e04..66966869218 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11716,7 +11716,7 @@ static CPUARMTBFlags rebuild_hflags_a32(CPUARMState
*env, int fp_el,
DP_TBFLAG_A32(flags, VFPEN, 1);
}
- if (el < 2 && env->cp15.hstr_el2 &&
+ if (el < 2 && env->cp15.hstr_el2 && arm_is_el2_enabled(env) &&
(arm_hcr_el2_eff(env) & (HCR_E2H | HCR_TGE)) != (HCR_E2H | HCR_TGE)) {