From: Marc Zyngier <maz@kernel.org>
To: "Pierre-Clément Tosi" <ptosi@google.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH 05/10] KVM: arm64: nVHE: Add EL2 sync exception handler
Date: Sun, 17 Mar 2024 11:42:44 +0000 [thread overview]
Message-ID: <86bk7d13uz.wl-maz@kernel.org> (raw)
In-Reply-To: <cebafe40b170589d52e2ef66f3bfac7396fa1f56.1710446682.git.ptosi@google.com>
On Thu, 14 Mar 2024 20:24:31 +0000,
Pierre-Clément Tosi <ptosi@google.com> wrote:
>
> Introduce handlers for EL2{t,h} synchronous exceptions distinct from
> handlers for other "invalid" exceptions when running with the nVHE host
> vector. This will allow a future patch to handle CFI (synchronous)
> errors without affecting other classes of exceptions.
>
> Remove superfluous SP overflow check from the non-synchronous
> handlers.
Why are they superfluous? Because we are panic'ing? Detecting a stack
overflow is pretty valuable in any circumstances.
>
> Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/host.S | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
> index 27c989c4976d..1b9111c2b480 100644
> --- a/arch/arm64/kvm/hyp/nvhe/host.S
> +++ b/arch/arm64/kvm/hyp/nvhe/host.S
> @@ -183,7 +183,7 @@ SYM_FUNC_END(__host_hvc)
> .endif
> .endm
>
> -.macro invalid_host_el2_vect
> +.macro host_el2_sync_vect
> .align 7
>
> /*
> @@ -221,6 +221,11 @@ SYM_FUNC_END(__host_hvc)
> b __hyp_do_panic
> .endm
>
> +.macro invalid_host_el2_vect
> + .align 7
> + b __hyp_panic
> +.endm
> +
> /*
> * The host vector does not use an ESB instruction in order to avoid consuming
> * SErrors that should only be consumed by the host. Guest entry is deferred by
> @@ -233,12 +238,12 @@ SYM_FUNC_END(__host_hvc)
> */
> .align 11
> SYM_CODE_START(__kvm_hyp_host_vector)
> - invalid_host_el2_vect // Synchronous EL2t
> + host_el2_sync_vect // Synchronous EL2t
The real question is: under which circumstances would running with
SP_EL0 be valid? I cannot see good reason for it.
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: "Pierre-Clément Tosi" <ptosi@google.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH 05/10] KVM: arm64: nVHE: Add EL2 sync exception handler
Date: Sun, 17 Mar 2024 11:42:44 +0000 [thread overview]
Message-ID: <86bk7d13uz.wl-maz@kernel.org> (raw)
In-Reply-To: <cebafe40b170589d52e2ef66f3bfac7396fa1f56.1710446682.git.ptosi@google.com>
On Thu, 14 Mar 2024 20:24:31 +0000,
Pierre-Clément Tosi <ptosi@google.com> wrote:
>
> Introduce handlers for EL2{t,h} synchronous exceptions distinct from
> handlers for other "invalid" exceptions when running with the nVHE host
> vector. This will allow a future patch to handle CFI (synchronous)
> errors without affecting other classes of exceptions.
>
> Remove superfluous SP overflow check from the non-synchronous
> handlers.
Why are they superfluous? Because we are panic'ing? Detecting a stack
overflow is pretty valuable in any circumstances.
>
> Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/host.S | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
> index 27c989c4976d..1b9111c2b480 100644
> --- a/arch/arm64/kvm/hyp/nvhe/host.S
> +++ b/arch/arm64/kvm/hyp/nvhe/host.S
> @@ -183,7 +183,7 @@ SYM_FUNC_END(__host_hvc)
> .endif
> .endm
>
> -.macro invalid_host_el2_vect
> +.macro host_el2_sync_vect
> .align 7
>
> /*
> @@ -221,6 +221,11 @@ SYM_FUNC_END(__host_hvc)
> b __hyp_do_panic
> .endm
>
> +.macro invalid_host_el2_vect
> + .align 7
> + b __hyp_panic
> +.endm
> +
> /*
> * The host vector does not use an ESB instruction in order to avoid consuming
> * SErrors that should only be consumed by the host. Guest entry is deferred by
> @@ -233,12 +238,12 @@ SYM_FUNC_END(__host_hvc)
> */
> .align 11
> SYM_CODE_START(__kvm_hyp_host_vector)
> - invalid_host_el2_vect // Synchronous EL2t
> + host_el2_sync_vect // Synchronous EL2t
The real question is: under which circumstances would running with
SP_EL0 be valid? I cannot see good reason for it.
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:[~2024-03-17 11:42 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 20:23 [PATCH 00/10] KVM: arm64: Add support for hypervisor kCFI Pierre-Clément Tosi
2024-03-14 20:23 ` Pierre-Clément Tosi
2024-03-14 20:23 ` [PATCH 01/10] KVM: arm64: Fix clobbered ELR in sync abort Pierre-Clément Tosi
2024-03-14 20:23 ` Pierre-Clément Tosi
2024-03-17 12:26 ` Marc Zyngier
2024-03-17 12:26 ` Marc Zyngier
2024-03-14 20:23 ` [PATCH 02/10] KVM: arm64: Fix __pkvm_init_switch_pgd C signature Pierre-Clément Tosi
2024-03-14 20:23 ` Pierre-Clément Tosi
2024-03-14 20:23 ` [PATCH 03/10] KVM: arm64: Pass pointer to __pkvm_init_switch_pgd Pierre-Clément Tosi
2024-03-14 20:23 ` Pierre-Clément Tosi
2024-03-14 20:24 ` [PATCH 04/10] KVM: arm64: nVHE: Simplify __guest_exit_panic path Pierre-Clément Tosi
2024-03-14 20:24 ` Pierre-Clément Tosi
2024-03-14 20:24 ` [PATCH 05/10] KVM: arm64: nVHE: Add EL2 sync exception handler Pierre-Clément Tosi
2024-03-14 20:24 ` Pierre-Clément Tosi
2024-03-17 11:42 ` Marc Zyngier [this message]
2024-03-17 11:42 ` Marc Zyngier
2024-04-10 14:44 ` Pierre-Clément Tosi
2024-04-10 14:44 ` Pierre-Clément Tosi
2024-03-14 20:24 ` [PATCH 06/10] KVM: arm64: nVHE: gen-hyprel: Skip R_AARCH64_ABS32 Pierre-Clément Tosi
2024-03-14 20:24 ` Pierre-Clément Tosi
2024-03-14 20:25 ` [PATCH 07/10] KVM: arm64: VHE: Mark __hyp_call_panic __noreturn Pierre-Clément Tosi
2024-03-14 20:25 ` Pierre-Clément Tosi
2024-03-14 20:25 ` [PATCH 08/10] arm64: Move esr_comment() to <asm/esr.h> Pierre-Clément Tosi
2024-03-14 20:25 ` Pierre-Clément Tosi
2024-03-17 12:50 ` Marc Zyngier
2024-03-17 12:50 ` Marc Zyngier
2024-03-14 20:25 ` [PATCH 09/10] KVM: arm64: nVHE: Support CONFIG_CFI_CLANG at EL2 Pierre-Clément Tosi
2024-03-14 20:25 ` Pierre-Clément Tosi
2024-03-17 13:09 ` Marc Zyngier
2024-03-17 13:09 ` Marc Zyngier
2024-04-10 14:58 ` Pierre-Clément Tosi
2024-04-10 14:58 ` Pierre-Clément Tosi
2024-03-14 20:26 ` [PATCH 10/10] KVM: arm64: Improve CONFIG_CFI_CLANG error message Pierre-Clément Tosi
2024-03-14 20:26 ` Pierre-Clément Tosi
2024-03-14 22:40 ` [PATCH 00/10] KVM: arm64: Add support for hypervisor kCFI Marc Zyngier
2024-03-14 22:40 ` Marc Zyngier
2024-03-15 10:22 ` Pierre-Clément Tosi
2024-03-15 10:22 ` Pierre-Clément Tosi
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=86bk7d13uz.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=ptosi@google.com \
--cc=suzuki.poulose@arm.com \
--cc=yuzenghui@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.