linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).