Re: [PATCH v4 1/2] cxl/core: introduce device reporting poison hanlding

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Thu,  8 Aug 2024 23:13:27 +0800
Shiyang Ruan <ruansy.fnst@fujitsu.com> wrote:

> CXL device can find&report memory problems, even before MCE is detected
> by CPU.  AFAIK, the current kernel only traces POISON error event
> from FW-First/OS-First path, but it doesn't handle them, neither
> notify processes who are using the POISON page like MCE does.
> 
> Thus, user have to read logs from trace and find out which device
> reported the error and which applications are affected.  That is not
> an easy work and cannot be handled in time. 

These are async reports, so I'm not sure what 'in time' really means here.
If we get synchronous poison from a processor access it will be handled
via traditional means (MCE, ARM SEA etc)

Whether to handle async error reports (typically from scrub or because
the memory device received poison from someone else) the same way
should perhaps be a policy decision.  It should match what we do
for firmware first async reports though (any policy controls make sense
for both).

An example of this would be that an host OS might attempt a polite close
of an application might attempt a polite if we know there is poison
somewhere in a dataset it has access to. If that poison is never seen
synchronously (because that data is not read) then it my close
successfully rather than being killed.

If it's injected poison and we didn't see it synchronously we might
well not want to kill anything.

> Thus, it is needed to add
> the feature to make the work done automatically and quickly.  Once CXL
> device reports the POISON error (via FW-First/OS-First), kernel
> handles it immediately, similar to the flow when a MCE is triggered.
> 
> The current call trace of error reporting&handling looks like this:
> ```
> 1.  MCE (interrupt #18, while CPU consuming POISON)
>      -> do_machine_check()
>        -> mce_log()
>          -> notify chain (x86_mce_decoder_chain)
>            -> memory_failure()  
> 
> 2.a FW-First (optional, CXL device proactively find&report)
>      -> CXL device -> Firmware
>        -> OS: ACPI->APEI->GHES->CPER -> CXL driver -> trace  
>                                                   \-> memory_failure()
>                                                       ^----- ADD
> 2.b OS-First (optional, CXL device proactively find&report)
>      -> CXL device -> MSI
>        -> OS: CXL driver -> trace  
>                         \-> memory_failure()
>                             ^------------------------------- ADD
> ```
> This patch adds calling memory_failure() while CXL device reporting
> error is received, marked as "ADD" in figure above.

Typo in patch title.  handling
I've also dropped qemu-devel as this doesn't have anything to do with qemu.

> 
> Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>

Experienced RAS folk in the CC, how do you want this to work for
asynchoronous memory errors on CXL devices?