Re: [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up

2018-02-20 Thread Punit Agrawal
James Morse  writes:

> Hello!

Hi

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

[...]

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

All but the last patch applied cleanly on v4.16-rc2 for me.

Other than the comments I've already sent the patches look good to me.

FWIW,

Reviewed-by: Punit Agrawal 

Thanks,
Punit

>
>
> 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
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm


Re: [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up

2018-02-19 Thread Borislav Petkov
On Thu, Feb 15, 2018 at 06:55:55PM +, James Morse wrote:
> 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).

Thank you about those! This is how people should write 0/N introductory
messages with fancy new abbreviations.

:-)

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm