From: Marc Zyngier <maz@kernel.org>
To: Andrew Scull <ascull@google.com>
Cc: kernel-team@android.com, suzuki.poulose@arm.com,
catalin.marinas@arm.com, james.morse@arm.com,
linux-arm-kernel@lists.infradead.org,
Sudeep Holla <sudeep.holla@arm.com>,
will@kernel.org, kvmarm@lists.cs.columbia.edu,
julien.thierry.kdev@gmail.com
Subject: Re: [PATCH v4 10/19] KVM: arm64: Restore hyp when panicking in guest context
Date: Wed, 16 Sep 2020 12:20:34 +0100 [thread overview]
Message-ID: <87k0wuq871.wl-maz@kernel.org> (raw)
In-Reply-To: <20200915104643.2543892-11-ascull@google.com>
Hi Andrew,
On Tue, 15 Sep 2020 11:46:34 +0100,
Andrew Scull <ascull@google.com> wrote:
>
> If the guest context is loaded when a panic is triggered, restore the
> hyp context so e.g. the shadow call stack works when hyp_panic() is
> called and SP_EL0 is valid when the host's panic() is called.
>
> Use the hyp context's __hyp_running_vcpu field to track when hyp
> transitions to and from the guest vcpu so the exception handlers know
> whether the context needs to be restored.
>
> Signed-off-by: Andrew Scull <ascull@google.com>
> ---
> arch/arm64/include/asm/kvm_asm.h | 10 ++++++++++
> arch/arm64/kvm/hyp/entry.S | 24 ++++++++++++++++++++++++
> arch/arm64/kvm/hyp/hyp-entry.S | 5 ++---
> arch/arm64/kvm/hyp/include/hyp/switch.h | 4 +++-
> arch/arm64/kvm/hyp/nvhe/host.S | 5 +++++
> 5 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index fe51c06d480d..4df2bd8882bc 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -236,6 +236,16 @@ extern char __smccc_workaround_1_smc[__SMCCC_WORKAROUND_1_SMC_SZ];
> ldr \vcpu, [\ctxt, #HOST_CONTEXT_VCPU]
> .endm
>
> +.macro get_loaded_vcpu vcpu, ctxt
> + hyp_adr_this_cpu \ctxt, kvm_hyp_ctxt, \vcpu
> + ldr \vcpu, [\ctxt, #HOST_CONTEXT_VCPU]
> +.endm
> +
> +.macro set_loaded_vcpu vcpu, ctxt, tmp
> + hyp_adr_this_cpu \ctxt, kvm_hyp_ctxt, \tmp
> + str \vcpu, [\ctxt, #HOST_CONTEXT_VCPU]
> +.endm
> +
> /*
> * KVM extable for unexpected exceptions.
> * In the same format _asm_extable, but output to a different section so that
> diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
> index 38cca690a6ff..4787fc82790c 100644
> --- a/arch/arm64/kvm/hyp/entry.S
> +++ b/arch/arm64/kvm/hyp/entry.S
> @@ -86,6 +86,8 @@ alternative_else_nop_endif
> ret
>
> 1:
> + set_loaded_vcpu x0, x1, x2
> +
> add x29, x0, #VCPU_CONTEXT
>
> // Macro ptrauth_switch_to_guest format:
> @@ -116,6 +118,26 @@ alternative_else_nop_endif
> eret
> sb
>
> +SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL)
> + // x2-x29,lr: vcpu regs
> + // vcpu x0-x1 on the stack
> +
> + // If the hyp context is loaded, go straight to hyp_panic
> + get_loaded_vcpu x0, x1
> + cbz x0, hyp_panic
> +
> + // The hyp context is saved so make sure it is restored to allow
> + // hyp_panic to run at hyp and, subsequently, panic to run in the host.
> + // This makes use of __guest_exit to avoid duplication but sets the
> + // return address to tail call into hyp_panic. As a side effect, the
> + // current state is saved to the guest context but it will only be
> + // accurate if the guest had been completely restored.
> + hyp_adr_this_cpu x0, kvm_hyp_ctxt, x1
> + adr x1, hyp_panic
> + str x1, [x0, #CPU_XREG_OFFSET(30)]
> +
> + get_vcpu_ptr x1, x0
> +
> SYM_INNER_LABEL(__guest_exit, SYM_L_GLOBAL)
> // x0: return code
> // x1: vcpu
> @@ -163,6 +185,8 @@ SYM_INNER_LABEL(__guest_exit, SYM_L_GLOBAL)
> // Now restore the hyp regs
> restore_callee_saved_regs x2
>
> + set_loaded_vcpu xzr, x1, x2
> +
> alternative_if ARM64_HAS_RAS_EXTN
> // If we have the RAS extensions we can consume a pending error
> // without an unmask-SError and isb. The ESB-instruction consumed any
> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
> index f92489250dfc..bc9f53df46f5 100644
> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> @@ -145,7 +145,7 @@ el2_error:
> eret
> sb
>
> -.macro invalid_vector label, target = hyp_panic
> +.macro invalid_vector label, target = __guest_exit_panic
> .align 2
> SYM_CODE_START(\label)
> b \target
> @@ -186,10 +186,9 @@ check_preamble_length 661b, 662b
> .macro invalid_vect target
> .align 7
> 661:
> - b \target
> nop
> + stp x0, x1, [sp, #-16]!
> 662:
> - ldp x0, x1, [sp], #16
> b \target
>
> check_preamble_length 661b, 662b
> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index afe714056b97..821721b78ad9 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -509,6 +509,7 @@ static inline void __set_host_arch_workaround_state(struct kvm_vcpu *vcpu)
>
> static inline void __kvm_unexpected_el2_exception(void)
> {
> + extern char __guest_exit_panic[];
> unsigned long addr, fixup;
> struct exception_table_entry *entry, *end;
> unsigned long elr_el2 = read_sysreg(elr_el2);
> @@ -529,7 +530,8 @@ static inline void __kvm_unexpected_el2_exception(void)
> return;
> }
>
> - hyp_panic();
> + /* Trigger a panic after restoring the hyp context. */
> + write_sysreg(__guest_exit_panic, elr_el2);
> }
>
> #endif /* __ARM64_KVM_HYP_SWITCH_H__ */
> diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
> index da21fddcef75..9ab7814e6114 100644
> --- a/arch/arm64/kvm/hyp/nvhe/host.S
> +++ b/arch/arm64/kvm/hyp/nvhe/host.S
> @@ -75,6 +75,11 @@ SYM_FUNC_END(__hyp_do_panic)
>
> .macro invalid_host_vect
> .align 7
> + /* If a guest is loaded, panic out of it. */
> + stp x0, x1, [sp, #-16]!
> + get_loaded_vcpu x0, x1
> + cbnz x0, __guest_exit_panic
> + add sp, sp, #16
> b hyp_panic
> .endm
Given that we have switched vectors when entering the guest, is this
only to deal with the lack of an ISB when performing the VBAR_EL2
update?
Thanks,
M.
>
> --
> 2.28.0.618.gf4bc123cb7-goog
>
>
--
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:[~2020-09-16 11:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-15 10:46 [PATCH v4 00/19] Introduce separate nVHE hyp context Andrew Scull
2020-09-15 10:46 ` [PATCH v4 01/19] KVM: arm64: Remove __activate_vm wrapper Andrew Scull
2020-09-15 10:46 ` [PATCH v4 02/19] KVM: arm64: Remove hyp_panic arguments Andrew Scull
2020-09-15 10:46 ` [PATCH v4 03/19] KVM: arm64: Remove kvm_host_data_t typedef Andrew Scull
2020-09-15 10:46 ` [PATCH v4 04/19] KVM: arm64: Choose hyp symbol based on context Andrew Scull
2020-09-15 10:46 ` [PATCH v4 05/19] KVM: arm64: Save chosen hyp vector to a percpu variable Andrew Scull
2020-09-15 10:46 ` [PATCH v4 06/19] KVM: arm64: nVHE: Use separate vector for the host Andrew Scull
2020-09-15 10:46 ` [PATCH v4 07/19] KVM: arm64: nVHE: Don't consume host SErrors with ESB Andrew Scull
2020-09-15 10:46 ` [PATCH v4 08/19] KVM: arm64: Introduce hyp context Andrew Scull
2020-09-15 10:46 ` [PATCH v4 09/19] KVM: arm64: Update context references from host to hyp Andrew Scull
2020-09-15 10:46 ` [PATCH v4 10/19] KVM: arm64: Restore hyp when panicking in guest context Andrew Scull
2020-09-16 11:20 ` Marc Zyngier [this message]
2020-09-15 10:46 ` [PATCH v4 11/19] KVM: arm64: Share context save and restore macros Andrew Scull
2020-09-15 10:46 ` [PATCH v4 12/19] KVM: arm64: nVHE: Switch to hyp context for EL2 Andrew Scull
2020-09-16 13:14 ` Marc Zyngier
2020-09-15 10:46 ` [PATCH v4 13/19] KVM: arm64: nVHE: Handle hyp panics Andrew Scull
2020-09-15 10:46 ` [PATCH v4 14/19] KVM: arm64: nVHE: Pass pointers consistently to hyp-init Andrew Scull
2020-09-15 10:46 ` [PATCH v4 15/19] smccc: Define vendor hyp owned service call region Andrew Scull
2020-09-15 10:46 ` [PATCH v4 16/19] smccc: Use separate variables for args and results Andrew Scull
2020-09-15 10:46 ` [PATCH v4 17/19] KVM: arm64: nVHE: Migrate hyp interface to SMCCC Andrew Scull
2020-09-15 10:46 ` [PATCH v4 18/19] KVM: arm64: nVHE: Migrate hyp-init " Andrew Scull
2020-09-15 10:46 ` [PATCH v4 19/19] KVM: arm64: nVHE: Fix pointers during SMCCC convertion Andrew Scull
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=87k0wuq871.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=ascull@google.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=julien.thierry.kdev@gmail.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=sudeep.holla@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.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).