On 28/02/17 19:43, Baicar, Tyler wrote:True, would you suggest leaving these nmi_* calls or adding the rcu_* calls? And since that's only needed for this KVM case, shouldn't the rcu_* calls just replace the nmi_* calls here (outside of ghes_notify_sea)?
On 2/24/2017 3:42 AM, James Morse wrote:Just occurs to me: if we do this we need to add the rcu_read_lock() in
On 21/02/17 21:22, Tyler Baicar wrote:Makes sense, I can remove the nmi_* calls here.
Currently external aborts are unsupported by the guest abortThis nmi stuff was needed for synchronous aborts that may have interrupted
handling. Add handling for SEAs so that the host kernel reports
SEAs which occur in the guest kernel.
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index b2d57fc..403277b 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -602,6 +602,24 @@ static const char *fault_name(unsigned int esr)
}
/*
+ * Handle Synchronous External Aborts that occur in a guest kernel.
+ */
+int handle_guest_sea(unsigned long addr, unsigned int esr)
+{
+ if(IS_ENABLED(HAVE_ACPI_APEI_SEA)) {
+ nmi_enter();
+ ghes_notify_sea();
+ nmi_exit();
APEI's interrupts-masked code. We want to avoid trying to take the same set of
locks, hence taking the in_nmi() path through APEI. Here we know we interrupted
a guest, so there is no risk that we have interrupted APEI on the host.
ghes_notify_sea() can safely take the normal path.
ghes_notify_sea() as its not protected by the rcu/nmi weirdness.