qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel@nongnu.org
Cc: qemu-arm@nongnu.org, Tom Rini <trini@konsulko.com>,
	Michal Simek <michal.simek@xilinx.com>,
	Stephen Warren <swarren@wwwdotorg.org>
Subject: Re: [Qemu-devel] [PATCH] target/arm: Allow to switch from MON->HYP on AArch32
Date: Wed, 09 Jan 2019 16:10:37 +0000	[thread overview]
Message-ID: <871s5lx14y.fsf@linaro.org> (raw)
In-Reply-To: <20190109152430.32359-1-agraf@suse.de>


Alexander Graf <agraf@suse.de> writes:

> In U-boot, we switch from S-SVC -> MON -> HYP when we want to enter
> HYP mode. This dance seems to work ok (hence it's there in the code
> base), but breaks with current QEMU.

What EL is MON in this case? EL3? In which case I'm confused by the
terminology as the ARM ARM states:

  The principles of the ARMv8-A security model are:
  • If the implementation includes EL3, then it has two Security states, Secure and Non-secure, and:
    — EL3 exists only in Secure state.
    — A change from Non-secure state to Secure state can only occur on taking an exception to EL3.
    — A change from Secure state to Non-secure state can only occur on an exception return from EL3.

We don't currently implement ARMv8.4-SecEL2 but that adds secure EL2 but
as you can only switch security state in in/out of EL3 you have to be go
to the secure monitor before you enter it.

> The reason seems to be that we try to see whether we are entering
> HYP mode from the NS side. However, MON is always considered secure,
> so we always fall into an error case when going MON->HYP and never
> manage to actually do the switch.
>
> Fix this by not using a different helper function that does not bork
> when we're in MON state, as that switch is supposed to work.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  target/arm/helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index f00c141ef9..9bf8fbd8f9 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -6297,7 +6297,7 @@ static int bad_mode_switch(CPUARMState *env, int mode, CPSRWriteType write_type)
>          return 0;
>      case ARM_CPU_MODE_HYP:
>          return !arm_feature(env, ARM_FEATURE_EL2)
> -            || arm_current_el(env) < 2 || arm_is_secure(env);
> +            || arm_current_el(env) < 2 ||
> arm_is_secure_below_el3(env);

This seems to violate the rule that you can enter a NS state from
anything other than EL3.

>      case ARM_CPU_MODE_MON:
>          return arm_current_el(env) < 3;
>      default:


--
Alex Bennée

  reply	other threads:[~2019-01-09 16:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09 15:24 [Qemu-devel] [PATCH] target/arm: Allow to switch from MON->HYP on AArch32 Alexander Graf
2019-01-09 16:10 ` Alex Bennée [this message]
2019-01-09 16:19   ` Alexander Graf
2019-01-09 16:35   ` [Qemu-devel] [Qemu-arm] " Peter Maydell
2019-01-09 16:52 ` [Qemu-devel] " Peter Maydell
2019-01-09 16:59   ` Peter Maydell
2019-01-09 17:14     ` Alexander Graf
2019-01-09 23:08       ` Peter Maydell
2019-01-10  6:43         ` Alexander Graf
2019-01-10 10:34           ` Peter Maydell
2019-01-17 18:43             ` Peter Maydell

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=871s5lx14y.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=michal.simek@xilinx.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=swarren@wwwdotorg.org \
    --cc=trini@konsulko.com \
    /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).