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

[Shuai Xue <xueshuai@linux.alibaba.com>]

在 2025/9/19 02:45, Luck, Tony 写道:
>> 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")
> 
> 

Hi, Tony,

Thanks for the historical context. Understanding the IBM use case
and the original design intent is very helpful.

Best regards,
Shuai