Re: [PATCH] ACPI: APEI: GHES: Improve ghes_notify_nmi() status check
From: Yazen Ghannam
Date: Wed Nov 05 2025 - 16:19:42 EST
On Mon, Nov 03, 2025 at 03:05:47PM -0800, Tony Luck wrote:
> ghes_notify_nmi() is called for every NMI and must check whether the NMI was
> generated because an error was signalled by platform firmware.
>
> This check is very expensive as for each registered GHES NMI source it reads
> from the acpi generic address attached to this error source to get the physical
> address of the acpi_hest_generic_status block. It then checks the "block_status"
> to see if an error was logged.
>
> The ACPI/APEI code must create virtual mappings for each of those physical
> addresses, and tear them down afterwards. On an Icelake system this takes around
> 15,000 TSC cycles. Enough to disturb efforts to profile system performance.
>
> If that were not bad enough, there are some atomic accesses in the code path
> that will cause cache line bounces between CPUs. A problem that gets worse as
> the core count increases.
>
> But BIOS changes neither the acpi generic address nor the physical address of
> the acpi_hest_generic_status block. So this walk can be done once when the NMI is
> registered to save the virtual address (unmapping if the NMI is ever unregistered).
> The "block_status" can be checked directly in the NMI handler. This can be done
> without any atomic accesses.
>
> Resulting time to check that there is not an error record is around 900 cycles.
>
> Reported-by: Andi Kleen <andi.kleen@xxxxxxxxx>
> Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx>
>
> ---
> N.B. I only talked to an Intel BIOS expert about this. GHES code is shared by
> other architectures, so it would be wise to get confirmation on whether this
> assumption applies to all, or is Intel (or X86) specific.
I think that is how the ACPI spec describes it.
https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.html?highlight=hest#error-source-discovery
The HEST and other tables are fixed at init time. There's an ACPI notify
event for if/when a device method needs to be re-evaluted, but I don't
think anything in APEI expects that.
Thanks,
Yazen