KVM: arm64: Handle RAS SErrors from EL1 on guest exit
authorJames Morse <james.morse@arm.com>
Mon, 15 Jan 2018 19:39:04 +0000 (19:39 +0000)
committerCatalin Marinas <catalin.marinas@arm.com>
Tue, 16 Jan 2018 15:09:13 +0000 (15:09 +0000)
commit3368bd809764d3ef0810e16c1e1531fec32e8d8e
tree7a7baf0049b8dd2b1d8b22a7a89ce3bbe80b7e37
parentc60590b552bdf682043579b9b965e6224fbf65d9
KVM: arm64: Handle RAS SErrors from EL1 on guest exit

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.

For SError that interrupt a guest and are routed to EL2 the existing
behaviour is to inject an impdef SError into the guest.

Add code to handle RAS SError based on the ESR. For uncontained and
uncategorized errors arm64_is_fatal_ras_serror() will panic(), these
errors compromise the host too. All other error types are contained:
For the fatal errors the vCPU can't make progress, so we inject a virtual
SError. We ignore contained errors where we can make progress as if
we're lucky, we may not hit them again.

If only some of the CPUs support RAS the guest will see the cpufeature
sanitised version of the id registers, but we may still take RAS SError
on this CPU. Move the SError handling out of handle_exit() into a new
handler that runs before we can be preempted. This allows us to use
this_cpu_has_cap(), via arm64_is_ras_serror().

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
arch/arm/include/asm/kvm_host.h
arch/arm64/include/asm/kvm_host.h
arch/arm64/kvm/handle_exit.c
virt/kvm/arm/arm.c