From: James Morse <james.morse@arm.com>
To: linux-acpi@vger.kernel.org
Cc: kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
Borislav Petkov <bp@alien8.de>,
Christoffer Dall <christoffer.dall@linaro.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Rafael Wysocki <rjw@rjwysocki.net>, Len Brown <lenb@kernel.org>,
Tony Luck <tony.luck@intel.com>,
Tyler Baicar <tbaicar@codeaurora.org>,
Dongjiu Geng <gengdongjiu@huawei.com>,
Xie XiuQi <xiexiuqi@huawei.com>,
Punit Agrawal <punit.agrawal@arm.com>,
James Morse <james.morse@arm.com>
Subject: [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
Date: Thu, 15 Feb 2018 18:55:55 +0000 [thread overview]
Message-ID: <20180215185606.26736-1-james.morse@arm.com> (raw)
Hello!
The aim of this series is to wire arm64's SDEI into APEI.
What's SDEI? Its ARM's "Software Delegated Exception Interface" [0]. It's
used by firmware to tell the OS about firmware-first RAS events.
These Software exceptions can interrupt anything, so I describe them as
NMI-like. They aren't the only NMI-like way to notify the OS about
firmware-first RAS events, the ACPI spec also defines 'NOTFIY_SEA' and
'NOTIFY_SEI'.
(Acronyms: SEA, Synchronous External Abort. The CPU requested some memory,
but the owner of that memory said no. These are always synchronous with the
instruction that caused them. SEI, System-Error Interrupt, commonly called
SError. This is an asynchronous external abort, the memory-owner didn't say no
at the right point. Collectively these things are called external-aborts
How is firmware involved? It traps these and re-injects them into the kernel
once its written the CPER records).
APEI's GHES code only expects one source of NMI. If a platform implements
more than one of these mechanisms, APEI needs to handle the interaction.
'SEA' and 'SEI' can interact as 'SEI' is asynchronous. SDEI can interact
with itself: its exceptions can be 'normal' or 'critical', and firmware
could use both types for RAS. (errors using normal, 'panic-now' using
critical).
What does this series do?
Patches 1-3 refactor APEIs 'estatus queue' so it can be used for all
NMI-like notifications. This defers the NMI work to irq_work, which will
happen when we next unmask interrupts.
Patches 4&5 move the arch and KVM code around so that NMI-like notifications
are always called in_nmi().
Patch 6 splits the 'irq or nmi?' path through ghes_copy_tofrom_phys()
up to be per-ghes. This lets each ghes specify which other error-sources
it can share a fixmap-slot and lock with.
Patch 7 renames NOTIFY_SEA's use of NOTIFY_NMI's infrastructure, as we're
about to have multiple NMI-like users that can't share resources.
Pathes 8&9 add the SDEI helper, and notify methods for APEI.
After this, adding the last firmware-first piece for arm64 is simple
(and safe), and all our NMI-like notifications behave the same as x86's
NOTIFY_NMI.
All of this makes the race between memory_failure_queue() and
ret_to_user worse, as there is now always irq_work involved.
Patch 10 makes the reschedule to memory_failure() run as soon as possible.
Patch 11 makes sure the arch code knows whether the irq_work has run by
the time do_sea() returns. We can skip the signalling step if it has as
APEI has done its work.
ghes.c became clearer to me when I worked out that it has three sets of
functions with 'estatus' in the name. One is a pool of memory that can be
allocated-from atomically. This is grown/shrunk when new NMI users are
allocated.
The second is the estatus-cache, which holds recent notifications so it
can suppress notifications we've already handled.
The last it the estatus-queue, which holds data from NMI-like notifications
(in pool memory) to be processed from irq_work.
Testing?
Tested with the SDEI FVP based software model and a mocked up NOTFIY_SEA using
KVM. I've only build tested this on x86.
Trees... The changes outside APEI are tiny, but there will be some changes
to how arch/arm64/mm/fault.c generates signals, affecting do_sea() that will
cause conflicts with patch 5.
Thanks,
James
[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
James Morse (11):
ACPI / APEI: Move the estatus queue code up, and under its own ifdef
ACPI / APEI: Generalise the estatus queue's add/remove and notify code
ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi()
users
ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications
firmware: arm_sdei: Add ACPI GHES registration helper
ACPI / APEI: Add support for the SDEI GHES Notification type
mm/memory-failure: increase queued recovery work's priority
arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
arch/arm/include/asm/kvm_ras.h | 14 +
arch/arm/include/asm/system_misc.h | 5 -
arch/arm64/include/asm/acpi.h | 3 +
arch/arm64/include/asm/daifflags.h | 1 +
arch/arm64/include/asm/fixmap.h | 8 +-
arch/arm64/include/asm/kvm_ras.h | 29 ++
arch/arm64/include/asm/system_misc.h | 2 -
arch/arm64/kernel/acpi.c | 49 ++++
arch/arm64/mm/fault.c | 30 +-
drivers/acpi/apei/ghes.c | 533 ++++++++++++++++++++---------------
drivers/firmware/arm_sdei.c | 75 +++++
include/acpi/ghes.h | 5 +
include/linux/arm_sdei.h | 8 +
mm/memory-failure.c | 11 +-
virt/kvm/arm/mmu.c | 4 +-
15 files changed, 517 insertions(+), 260 deletions(-)
create mode 100644 arch/arm/include/asm/kvm_ras.h
create mode 100644 arch/arm64/include/asm/kvm_ras.h
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2018-02-15 18:58 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-15 18:55 James Morse [this message]
2018-02-15 18:55 ` [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef James Morse
2018-02-20 18:26 ` Punit Agrawal
2018-02-20 19:28 ` Borislav Petkov
2018-02-23 18:02 ` James Morse
2018-02-23 18:07 ` Borislav Petkov
2018-02-15 18:55 ` [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code James Morse
2018-02-20 18:26 ` Punit Agrawal
2018-02-23 18:21 ` James Morse
2018-03-01 15:01 ` Borislav Petkov
2018-03-01 18:06 ` Punit Agrawal
2018-03-01 22:35 ` Borislav Petkov
2018-03-07 18:15 ` James Morse
2018-03-08 10:44 ` Borislav Petkov
2018-03-19 14:29 ` James Morse
2018-03-27 17:25 ` Borislav Petkov
2018-03-28 16:30 ` James Morse
2018-04-17 15:10 ` Borislav Petkov
2018-02-15 18:55 ` [PATCH 03/11] ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue James Morse
2018-02-15 18:55 ` [PATCH 04/11] KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing James Morse
2018-02-15 18:56 ` [PATCH 05/11] arm64: KVM/mm: Move SEA handling behind a single 'claim' interface James Morse
2018-02-20 18:30 ` Punit Agrawal
2018-02-15 18:56 ` [PATCH 06/11] ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi() users James Morse
2018-02-20 21:18 ` Tyler Baicar
2018-02-22 17:47 ` James Morse
2018-02-15 18:56 ` [PATCH 07/11] ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications James Morse
2018-02-15 18:56 ` [PATCH 08/11] firmware: arm_sdei: Add ACPI GHES registration helper James Morse
2018-02-20 18:31 ` Punit Agrawal
2018-02-15 18:56 ` [PATCH 09/11] ACPI / APEI: Add support for the SDEI GHES Notification type James Morse
2018-02-15 18:56 ` [PATCH 10/11] mm/memory-failure: increase queued recovery work's priority James Morse
2018-02-15 18:56 ` [PATCH 11/11] arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work James Morse
2018-02-19 21:05 ` [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up Borislav Petkov
2018-02-20 18:42 ` Punit Agrawal
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=20180215185606.26736-1-james.morse@arm.com \
--to=james.morse@arm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=gengdongjiu@huawei.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=marc.zyngier@arm.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=punit.agrawal@arm.com \
--cc=rjw@rjwysocki.net \
--cc=tbaicar@codeaurora.org \
--cc=tony.luck@intel.com \
--cc=will.deacon@arm.com \
--cc=xiexiuqi@huawei.com \
/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).