linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
@ 2018-03-22 18:14 James Morse
  2018-03-22 18:14 ` [PATCH v2 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef James Morse
                   ` (10 more replies)
  0 siblings, 11 replies; 17+ messages in thread
From: James Morse @ 2018-03-22 18:14 UTC (permalink / raw)
  To: linux-acpi
  Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov, Marc Zyngier,
	Christoffer Dall, Will Deacon, Catalin Marinas, Naoya Horiguchi,
	Rafael Wysocki, Len Brown, Tony Luck, Tyler Baicar, Dongjiu Geng,
	Xie XiuQi, Punit Agrawal, James Morse

The aim of this series is to wire arm64's SDEI into APEI.

What changed since v1? The NMI-like GHES entries now have an additional
fixmap+lock, instead of choosing which lock to use, and being surprised
when it turns out all GHES are processed from process-context during
boot. (Thanks to Tyler for catching this...)
Some comments and code cleanup, noted in each patch.


The earlier boiler-plate:

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 changes the 'irq or nmi?' path through ghes_copy_tofrom_phys()
to be per-ghes. When called in_nmi(), the struct ghes is expected to
provide a fixmap slot and lock that is safe to use. NMI-like notifications
that mask each other can share these resources. Those that interact should
have their own fixmap slot and lock.

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 further firmware-first pieces 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 added a case where 'corrected errors' are discovered at probe time
to exercise ghes_probe() during boot. I've only build tested this on x86.


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 nmi_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             | 519 ++++++++++++++++++++---------------
 drivers/firmware/arm_sdei.c          |  75 +++++
 include/acpi/ghes.h                  |   4 +
 include/linux/arm_sdei.h             |   8 +
 mm/memory-failure.c                  |  11 +-
 virt/kvm/arm/mmu.c                   |   4 +-
 15 files changed, 505 insertions(+), 257 deletions(-)
 create mode 100644 arch/arm/include/asm/kvm_ras.h
 create mode 100644 arch/arm64/include/asm/kvm_ras.h

-- 
2.16.2

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2018-03-28 16:36 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-22 18:14 [PATCH v2 00/11] APEI in_nmi() rework and arm64 SDEI wire-up James Morse
2018-03-22 18:14 ` [PATCH v2 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef James Morse
2018-03-22 18:14 ` [PATCH v2 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code James Morse
2018-03-22 18:14 ` [PATCH v2 03/11] ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue James Morse
2018-03-22 18:14 ` [PATCH v2 04/11] KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing James Morse
2018-03-26 15:11   ` Marc Zyngier
2018-03-22 18:14 ` [PATCH v2 05/11] arm64: KVM/mm: Move SEA handling behind a single 'claim' interface James Morse
2018-03-26 17:49   ` Marc Zyngier
2018-03-28 16:30     ` James Morse
2018-03-22 18:14 ` [PATCH v2 06/11] ACPI / APEI: Make the nmi_fixmap_idx per-ghes to allow multiple in_nmi() users James Morse
2018-03-22 18:14 ` [PATCH v2 07/11] ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications James Morse
2018-03-22 18:14 ` [PATCH v2 08/11] firmware: arm_sdei: Add ACPI GHES registration helper James Morse
2018-03-25  1:41   ` kbuild test robot
2018-03-28 16:33     ` James Morse
2018-03-22 18:14 ` [PATCH v2 09/11] ACPI / APEI: Add support for the SDEI GHES Notification type James Morse
2018-03-22 18:14 ` [PATCH v2 10/11] mm/memory-failure: increase queued recovery work's priority James Morse
2018-03-22 18:14 ` [PATCH v2 11/11] arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work James Morse

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).