From: Marc Zyngier <maz@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, "Rafał Miłecki" <zajec5@gmail.com>,
"Will Deacon" <will@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Florian Fainelli" <f.fainelli@gmail.com>,
bcm-kernel-feedback-list@broadcom.com, kernel-team@android.com
Subject: Re: [PATCH 2/5] arm64: Handle UNDEF in the EL2 stub vectors
Date: Fri, 13 Aug 2021 18:41:36 +0100 [thread overview]
Message-ID: <87im091bu7.wl-maz@kernel.org> (raw)
In-Reply-To: <2f6bf17f-d235-8311-13d5-dcb3d00e23c4@arm.com>
On Fri, 13 Aug 2021 14:08:23 +0100,
Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-08-12 20:02, Marc Zyngier wrote:
> > As we want to handle the silly case where HVC has been disabled
> > from EL3, augment our ability to handle exception at EL2.
> >
> > Check for unknown exceptions (usually UNDEF) coming from EL2,
> > and treat them as a failing HVC call into the stubs. While
> > this isn't great and obviously doesn't catter for the gigantic
> > range of possible exceptions, it isn't any worse than what we
> > have today.
> >
> > Just don't try and use it for anything else.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kernel/hyp-stub.S | 19 ++++++++++++++++++-
> > 1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
> > index 43d212618834..026a34515b21 100644
> > --- a/arch/arm64/kernel/hyp-stub.S
> > +++ b/arch/arm64/kernel/hyp-stub.S
> > @@ -46,7 +46,16 @@ SYM_CODE_END(__hyp_stub_vectors)
> > .align 11
> > SYM_CODE_START_LOCAL(elx_sync)
> > - cmp x0, #HVC_SET_VECTORS
> > + mrs x4, spsr_el2
> > + and x4, x4, #PSR_MODE_MASK
> > + orr x4, x4, #1
> > + cmp x4, #PSR_MODE_EL2h
> > + b.ne 0f
> > + mrs x4, esr_el2
> > + eor x4, x4, #ESR_ELx_IL
> > + cbz x4, el2_undef
>
> Hmm, might it be neater to check ESR_EL2.ISS to see if we landed here
> for any reason *other* than a successfully-executed HVC?
We absolutely could. However, the sixpence question (yes, that's the
Brexit effect for you) is "what do you do with exceptions that are
neither UNDEF now HVC?".
We are taking a leap of faith by assuming that the only thing that
will UNDEF at EL2 while the stubs are installed is HVC. If anything
else occurs, I have no idea what to do with it. I guess we could always
ignore it instead of treating it as a HVC (as it is done at the
moment).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-08-13 17:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-12 19:02 [PATCH 0/5] arm64: Survival kit for SCR_EL3.HCE==0 conditions Marc Zyngier
2021-08-12 19:02 ` [PATCH 1/5] arm64: Directly expand __init_el2_nvhe_prepare_eret where needed Marc Zyngier
2021-08-12 19:02 ` [PATCH 2/5] arm64: Handle UNDEF in the EL2 stub vectors Marc Zyngier
2021-08-13 13:08 ` Robin Murphy
2021-08-13 17:41 ` Marc Zyngier [this message]
2021-08-13 18:17 ` Robin Murphy
2021-08-14 9:38 ` Marc Zyngier
2021-08-12 19:02 ` [PATCH 3/5] arm64: Detect disabled HVC early Marc Zyngier
2021-08-12 19:47 ` Rafał Miłecki
2021-08-13 9:05 ` Will Deacon
2021-08-13 17:33 ` Marc Zyngier
2021-08-12 19:02 ` [PATCH 4/5] arm64: Warn on booting at EL2 with HVC disabled Marc Zyngier
2021-08-12 19:58 ` Rafał Miłecki
2021-08-12 19:02 ` [PATCH 5/5] arm64: Document the requirement for SCR_EL3.HCE Marc Zyngier
2021-08-24 10:49 ` Catalin Marinas
2021-08-24 10:52 ` Mark Rutland
2021-08-15 7:28 ` [PATCH 0/5] arm64: Survival kit for SCR_EL3.HCE==0 conditions Florian Fainelli
2021-08-15 9:27 ` Marc Zyngier
2021-08-22 11:31 ` Florian Fainelli
2021-08-24 16:19 ` (subset) " Catalin Marinas
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=87im091bu7.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=ardb@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=catalin.marinas@arm.com \
--cc=f.fainelli@gmail.com \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=zajec5@gmail.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).