Re: [PATCH] ACPI: APEI: GHES: Improve ghes_notify_nmi() status check

["Luck, Tony" <tony.luck@intel.com>]

On Wed, Nov 05, 2025 at 04:19:24PM -0500, Yazen Ghannam wrote:
> On Mon, Nov 03, 2025 at 03:05:47PM -0800, Tony Luck wrote:
> > 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.

Yazen,

Thanks for looking.

James Morse pointed me to the fact that HAVE_ACPI_APEI_NMI
is only selected by arch/x86/Kconfig. So scope is limited
to x86.

That "18.3 Error Source Discovery" section of the ACPI spec feels
pretty vague. The "During initialization, OSPM examines the tables"
bit is comforting, but I was worried that although the tables are
static (so the generic ACPI address from the NMI error source
shouldn't change) there is an extra level of indirection where
that points to a location that holds the address of the error
status block. Some might not consider that as part of the "tables".

Further pondering has me 99% convinced that there would be no
reason for firmware to update that pointer (though it has led
me to wonder why that indirection exists).

Rafael: I think this patch is good to go.

-Tony