From: cdall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 14/16] KVM: arm64: Take pending SErrors on entry to the guest
Date: Tue, 1 Aug 2017 14:53:06 +0200 [thread overview]
Message-ID: <20170801125306.GF5176@cbox> (raw)
In-Reply-To: <20170728141019.9084-15-james.morse@arm.com>
Hi James,
On Fri, Jul 28, 2017 at 03:10:17PM +0100, James Morse wrote:
> SErrors due to RAS are either taken as an SError, or deferred because
> of an Error Synchronization Barrier (ESB). Systems that support the RAS
> extensions are very likely to have firmware-first handling of these
> errors, taking all SErrors to EL3.
>
> Add {I,}ESB support to KVM and be prepared to handle any resulting SError
> if we are notified directly. (i.e. no firmware-first handling). Do this
> for the cases where we can take the SError instead of deferring it.
Sorry, I forgot how this works again. If we do have firmware-first, are
we sure that the firmware doesn't just emulate the SError to EL2,
resulting in it looking the same whether or not we have firmware-first?
(perhaps the firmware-first thing clearly defines what should happen
when the firmware detects an SError?)
>
> With VHE KVM is covered by the host's setting of SCTLR_EL1.IESB: unmask
> SError when entering a guest. This will hyp-panic if there was an SError
> pending during world switch (and we don't have firmware first). Make
> sure this only happens when its KVM's 'fault' by adding an ESB to
nit: it's
> __kvm_call_hyp().
>
> On systems without the RAS extensions a pending SError triggered by KVM's
> world switch will no longer be blamed on the guest, causing a panic
> instead.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> arch/arm64/include/asm/assembler.h | 1 +
> arch/arm64/kvm/hyp.S | 1 +
> arch/arm64/kvm/hyp/entry.S | 18 ++++++++++++++++++
> 3 files changed, 20 insertions(+)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index e2bb551f59f7..e440fba6d0fe 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -29,6 +29,7 @@
> #include <asm/page.h>
> #include <asm/pgtable-hwdef.h>
> #include <asm/ptrace.h>
> +#include <asm/sysreg.h>
> #include <asm/thread_info.h>
>
> .macro save_and_disable_daif, flags
> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
> index 952f6cb9cf72..e96a5f6afecd 100644
> --- a/arch/arm64/kvm/hyp.S
> +++ b/arch/arm64/kvm/hyp.S
> @@ -40,6 +40,7 @@
> * arch/arm64/kernel/hyp_stub.S.
> */
> ENTRY(__kvm_call_hyp)
> + esb
are esb instructions ignored on earlier versions than ARMv8.2? (I
couldn't easily determine this from the spec)
So this is not necessarily the world switch path we're entering (as
hinted in the commit message), but we could also be doing TLB
maintenance. Is this still going to work in that case?
> alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
> hvc #0
> ret
> diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
> index 12ee62d6d410..cec18df5a324 100644
> --- a/arch/arm64/kvm/hyp/entry.S
> +++ b/arch/arm64/kvm/hyp/entry.S
> @@ -49,6 +49,21 @@
> ldp x29, lr, [\ctxt, #CPU_XREG_OFFSET(29)]
> .endm
>
> +/* We have an implicit esb if we have VHE and IESB. */
> +.macro kvm_explicit_esb
> + alternative_if_not ARM64_HAS_RAS_EXTN
> + b 998f
> + alternative_else_nop_endif
> + alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
> + esb
> + b 998f
> + alternative_else_nop_endif
> + alternative_if_not ARM64_HAS_IESB
> + esb
> + alternative_else_nop_endif
> +998:
> +.endm
> +
> /*
> * u64 __guest_enter(struct kvm_vcpu *vcpu,
> * struct kvm_cpu_context *host_ctxt);
> @@ -85,6 +100,9 @@ ENTRY(__guest_enter)
> ldr x18, [x18, #CPU_XREG_OFFSET(18)]
>
> // Do not touch any register after this!
> +
> + enable_serror // Don't defer an IESB SError
> + kvm_explicit_esb
> eret
> ENDPROC(__guest_enter)
>
> --
> 2.13.2
>
Thanks,
-Christoffer
next prev parent reply other threads:[~2017-08-01 12:53 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 14:10 [PATCH v2 00/16] SError rework + v8.2 RAS and IESB cpufeature support James Morse
2017-07-28 14:10 ` [PATCH v2 01/16] arm64: explicitly mask all exceptions James Morse
2017-07-28 14:10 ` [PATCH v2 02/16] arm64: introduce an order for exceptions James Morse
2017-07-28 14:10 ` [PATCH v2 03/16] arm64: unmask all exceptions from C code on CPU startup James Morse
2017-07-28 14:10 ` [PATCH v2 04/16] arm64: entry.S: mask all exceptions during kernel_exit James Morse
2017-07-28 14:10 ` [PATCH v2 05/16] arm64: entry.S: move enable_step_tsk into kernel_exit James Morse
2017-07-28 14:10 ` [PATCH v2 06/16] arm64: entry.S: convert elX_sync James Morse
2017-08-09 17:25 ` Catalin Marinas
2017-08-10 16:57 ` James Morse
2017-08-11 17:24 ` James Morse
2017-07-28 14:10 ` [PATCH v2 07/16] arm64: entry.S: convert elX_irq James Morse
2017-07-28 14:10 ` [PATCH v2 08/16] arm64: entry.S: move SError handling into a C function for future expansion James Morse
2017-07-28 14:10 ` [PATCH v2 09/16] arm64: cpufeature: Detect CPU RAS Extentions James Morse
2017-07-28 14:10 ` [PATCH v2 10/16] arm64: kernel: Survive corrected RAS errors notified by SError James Morse
2017-09-13 20:52 ` Baicar, Tyler
2017-09-14 12:58 ` James Morse
2017-07-28 14:10 ` [PATCH v2 11/16] arm64: kernel: Handle deferred SError on kernel entry James Morse
2017-08-03 17:03 ` James Morse
2017-07-28 14:10 ` [PATCH v2 12/16] arm64: entry.S: Make eret restartable James Morse
2017-07-28 14:10 ` [PATCH v2 13/16] arm64: cpufeature: Enable Implicit ESB on entry/return-from EL1 James Morse
2017-07-28 14:10 ` [PATCH v2 14/16] KVM: arm64: Take pending SErrors on entry to the guest James Morse
2017-08-01 12:53 ` Christoffer Dall [this message]
2017-07-28 14:10 ` [PATCH v2 15/16] KVM: arm64: Save ESR_EL2 on guest SError James Morse
2017-08-01 13:25 ` Christoffer Dall
2017-07-28 14:10 ` [PATCH v2 16/16] KVM: arm64: Handle deferred SErrors consumed on guest exit James Morse
2017-08-01 13:18 ` Christoffer Dall
2017-08-03 17:03 ` James Morse
2017-08-04 13:12 ` Christoffer Dall
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=20170801125306.GF5176@cbox \
--to=cdall@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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).