From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 12/13] KVM: arm64: Handle RAS SErrors from EL2 on guest exit
Date: Fri, 19 Jan 2018 20:54:42 +0100 [thread overview]
Message-ID: <20180119195442.GI21802@cbox> (raw)
In-Reply-To: <20180115193906.30053-13-james.morse@arm.com>
On Mon, Jan 15, 2018 at 07:39:05PM +0000, James Morse wrote:
> We expect to have firmware-first handling of RAS SErrors, with errors
> notified via an APEI method. For systems without firmware-first, add
> some minimal handling to KVM.
>
> There are two ways KVM can take an SError due to a guest, either may be a
> RAS error: we exit the guest due to an SError routed to EL2 by HCR_EL2.AMO,
> or we take an SError from EL2 when we unmask PSTATE.A from __guest_exit.
>
> The current SError from EL2 code unmasks SError and tries to fence any
> pending SError into a single instruction window. It then leaves SError
> unmasked.
>
> With the v8.2 RAS Extensions we may take an SError for a 'corrected'
> error, but KVM is only able to handle SError from EL2 if they occur
> during this single instruction window...
>
> The RAS Extensions give us a new instruction to synchronise and
> consume SErrors. The RAS Extensions document (ARM DDI0587),
> '2.4.1 ESB and Unrecoverable errors' describes ESB as synchronising
> SError interrupts generated by 'instructions, translation table walks,
> hardware updates to the translation tables, and instruction fetches on
> the same PE'. This makes ESB equivalent to KVMs existing
> 'dsb, mrs-daifclr, isb' sequence.
>
> Use the alternatives to synchronise and consume any SError using ESB
> instead of unmasking and taking the SError. Set ARM_EXIT_WITH_SERROR_BIT
> in the exit_code so that we can restart the vcpu if it turns out this
> SError has no impact on the vcpu.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> Changes since v4:
> * Moved the SError handling into handle_exit_early()
> * Dropped Marc & Christoffer's Reviewed-by due to handle_exit_early().
>
I realize this is queued, but for good measure, I'm still happy with
this change after handle_exit_early().
Thanks,
-Christoffer
next prev parent reply other threads:[~2018-01-19 19:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-15 19:38 [PATCH v6 00/13] arm64/KVM: RAS & IESB for firmware first support James Morse
2018-01-15 19:38 ` [PATCH v6 01/13] arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early James Morse
2018-01-15 19:38 ` [PATCH v6 02/13] arm64: sysreg: Move to use definitions for all the SCTLR bits James Morse
2018-01-15 19:38 ` [PATCH v6 03/13] arm64: cpufeature: Detect CPU RAS Extentions James Morse
[not found] ` <78d4374a-f75c-6860-38ab-6373ffae3eee@huawei.com>
2018-01-22 19:32 ` James Morse
2018-01-23 9:06 ` gengdongjiu
2018-01-23 19:05 ` James Morse
2018-01-25 8:27 ` gengdongjiu
2018-01-15 19:38 ` [PATCH v6 04/13] arm64: kernel: Survive corrected RAS errors notified by SError James Morse
2018-01-15 19:38 ` [PATCH v6 05/13] arm64: Unconditionally enable IESB on exception entry/return for firmware-first James Morse
2018-01-15 19:38 ` [PATCH v6 06/13] arm64: kernel: Prepare for a DISR user James Morse
2018-01-15 19:39 ` [PATCH v6 07/13] KVM: arm/arm64: mask/unmask daif around VHE guests James Morse
2018-01-15 19:39 ` [PATCH v6 08/13] KVM: arm64: Set an impdef ESR for Virtual-SError using VSESR_EL2 James Morse
2018-01-15 19:39 ` [PATCH v6 09/13] KVM: arm64: Save/Restore guest DISR_EL1 James Morse
2018-01-15 19:39 ` [PATCH v6 10/13] KVM: arm64: Save ESR_EL2 on guest SError James Morse
2018-01-15 19:39 ` [PATCH v6 11/13] KVM: arm64: Handle RAS SErrors from EL1 on guest exit James Morse
2018-01-19 19:20 ` Christoffer Dall
2018-01-22 18:18 ` James Morse
2018-01-23 15:32 ` Christoffer Dall
2018-01-30 19:18 ` James Morse
2018-01-15 19:39 ` [PATCH v6 12/13] KVM: arm64: Handle RAS SErrors from EL2 " James Morse
2018-01-19 19:54 ` Christoffer Dall [this message]
2018-01-15 19:39 ` [PATCH v6 13/13] KVM: arm64: Emulate RAS error registers and set HCR_EL2's TERR & TEA James Morse
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=20180119195442.GI21802@cbox \
--to=christoffer.dall@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).