RE: PATCH v3 ACPI: APEI: GHES: Don't offline huge pages just because BIOS asked

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

> Thank you for your detailed explanation. I believe this is exactly the problem
> we're encountering in our production environment.
>
> As you mentioned, memory access is typically interleaved between channels. When
> the per-rank threshold is exceeded, soft-offlining the last accessed address
> seems unreasonable - regardless of whether it's a 4KB page or a huge page. The
> error accumulation happens at the rank level, but the action is taken on a
> specific page that happened to trigger the threshold, which doesn't address the
> underlying issue.
>
> I'm curious about the intended use case for the CPER_SEC_ERROR_THRESHOLD_EXCEEDED
> flag. What scenario was Intel BIOS expecting the OS to handle when this flag is set?
> Is there a specific interpretation of "threshold exceeded" that would make
> page-level offline action meaningful? If not, how about disabling soft offline from
> GHES and leave that to userspace tools like rasdaemon (mcelog) ?

The original use case was defined by IBM [1] (that division is now part of Lenovo).
IBM BIOS enabled a firmware first mode to handle errors, cutting the OS out of
the picture. But the challenge with this was how to handle a case where the BIOS
identified a recurring problem on a specific memory address. The solution proposed
was to use GHES notification using the CPER_SEC_ERROR_THRESHOLD_EXCEEDED
flag to let the OS know that this corrected error needs some action.

-Tony

[1] cf870c70a194 ("mce: acpi/apei: Soft-offline a page on firmware GHES notification")