From: Richard Henderson <richard.henderson@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>,
qemu-arm@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [PATCH 06/14] target/arm/ptw: Pass an ARMSecuritySpace to arm_hcr_el2_eff_secstate()
Date: Sun, 23 Jul 2023 16:24:57 +0100 [thread overview]
Message-ID: <230dd650-846f-7105-7add-43fa2d03dad7@linaro.org> (raw)
In-Reply-To: <20230714154648.327466-7-peter.maydell@linaro.org>
On 7/14/23 16:46, Peter Maydell wrote:
> arm_hcr_el2_eff_secstate() takes a bool secure, which it uses to
> determine whether EL2 is enabled in the current security state.
> With the advent of FEAT_RME this is no longer sufficient, because
> EL2 can be enabled for Secure state but not for Root, and both
> of those will pass 'secure == true' in the callsites in ptw.c.
>
> As it happens in all of our callsites in ptw.c we either avoid making
> the call or else avoid using the returned value if we're doing a
> translation for Root, so this is not a behaviour change even if the
> experimental FEAT_RME is enabled. But it is less confusing in the
> ptw.c code if we avoid the use of a bool secure that duplicates some
> of the information in the ArmSecuritySpace argument.
>
> Make arm_hcr_el2_eff_secstate() take an ARMSecuritySpace argument
> instead.
>
> Note that since arm_hcr_el2_eff() uses the return value from
> arm_security_space_below_el3() for the 'space' argument, its
> behaviour does not change even when at EL3 (Root security state) and
> it continues to tell you what EL2 would be if you were in it.
>
> Signed-off-by: Peter Maydell<peter.maydell@linaro.org>
> ---
> target/arm/cpu.h | 2 +-
> target/arm/helper.c | 7 ++++---
> target/arm/ptw.c | 13 +++++--------
> 3 files changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 4d6c0f95d59..3743a9e2f8a 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -2555,7 +2555,7 @@ static inline bool arm_is_el2_enabled(CPUARMState *env)
> * "for all purposes other than a direct read or write access of HCR_EL2."
> * Not included here is HCR_RW.
> */
> -uint64_t arm_hcr_el2_eff_secstate(CPUARMState *env, bool secure);
> +uint64_t arm_hcr_el2_eff_secstate(CPUARMState *env, ARMSecuritySpace space);
> uint64_t arm_hcr_el2_eff(CPUARMState *env);
> uint64_t arm_hcrx_el2_eff(CPUARMState *env);
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index d08c058e424..1e45fdb47c9 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -5731,11 +5731,12 @@ static void hcr_writelow(CPUARMState *env, const ARMCPRegInfo *ri,
> * Bits that are not included here:
> * RW (read from SCR_EL3.RW as needed)
> */
> -uint64_t arm_hcr_el2_eff_secstate(CPUARMState *env, bool secure)
> +uint64_t arm_hcr_el2_eff_secstate(CPUARMState *env, ARMSecuritySpace space)
> {
> uint64_t ret = env->cp15.hcr_el2;
>
> - if (!arm_is_el2_enabled_secstate(env, secure)) {
> + if (space == ARMSS_Root ||
> + !arm_is_el2_enabled_secstate(env, arm_space_is_secure(space))) {
> /*
This is confusing, as without any larger context it certainly looks wrong.
> @@ -230,7 +230,7 @@ static bool regime_translation_disabled(CPUARMState *env, ARMMMUIdx mmu_idx,
> }
> }
>
> - hcr_el2 = arm_hcr_el2_eff_secstate(env, is_secure);
> + hcr_el2 = arm_hcr_el2_eff_secstate(env, space);
Here, it's not clear, and could produce an "incorrect" result, though of course the value
is not actually used unless mmu_idx requires it.
It might be better to sink the computation down into the two cases that require it. With
that, a local definition like
static inline uint64_t arm_hcr_el2_ptwspace(...)
{
assert(space != ARMSS_Root);
return arm_hcr_el2_eff_secstate(env, arm_space_is_secure(space));
}
could be the thing.
r~
next prev parent reply other threads:[~2023-07-23 15:26 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 15:46 [PATCH 00/14] target/arm/ptw: Cleanups and a few bugfixes Peter Maydell
2023-07-14 15:46 ` [PATCH 01/14] target/arm/ptw: Don't set fi->s1ptw for UnsuppAtomicUpdate fault Peter Maydell
2023-07-23 9:22 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 02/14] target/arm/ptw: Don't report GPC faults on stage 1 ptw as stage2 faults Peter Maydell
2023-07-23 9:34 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 03/14] target/arm/ptw: Set s1ns bit in fault info more consistently Peter Maydell
2023-07-23 9:54 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 04/14] target/arm/ptw: Pass ptw into get_phys_addr_pmsa*() and get_phys_addr_disabled() Peter Maydell
2023-07-23 10:25 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 05/14] target/arm/ptw: Pass ARMSecurityState to regime_translation_disabled() Peter Maydell
2023-07-23 10:25 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 06/14] target/arm/ptw: Pass an ARMSecuritySpace to arm_hcr_el2_eff_secstate() Peter Maydell
2023-07-23 15:24 ` Richard Henderson [this message]
2023-07-24 13:42 ` Peter Maydell
2023-07-24 14:38 ` Peter Maydell
2023-07-25 18:36 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 07/14] target/arm/ptw: Only fold in NSTable bit effects in Secure state Peter Maydell
2023-07-23 15:29 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 08/14] target/arm/ptw: Remove last uses of ptw->in_secure Peter Maydell
2023-07-23 15:35 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 09/14] target/arm/ptw: Remove S1Translate::in_secure Peter Maydell
2023-07-23 15:48 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 10/14] target/arm/ptw: Drop S1Translate::out_secure Peter Maydell
2023-07-23 15:49 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 11/14] target/arm/ptw: Set attributes correctly for MMU disabled data accesses Peter Maydell
2023-07-23 15:50 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 12/14] target/arm/ptw: Check for block descriptors at invalid levels Peter Maydell
2023-07-23 15:58 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 13/14] target/arm/ptw: Report stage 2 fault level for stage 2 faults on stage 1 ptw Peter Maydell
2023-07-23 16:00 ` Richard Henderson
2023-07-14 15:46 ` [PATCH 14/14] target/arm: Adjust PAR_EL1.SH for Device and Normal-NC memory types Peter Maydell
2023-07-23 16:02 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=230dd650-846f-7105-7add-43fa2d03dad7@linaro.org \
--to=richard.henderson@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).