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

[Shiyang Ruan <ruansy.fnst@fujitsu.com>]

在 2024/8/27 23:46, Jonathan Cameron 写道:
> 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.

'in time' may not be appropriate.  I think 'ASAP' is better.  I just 
want to say: comparing with users finding out the errors from trace logs 
and notifying apps manually, kernel handler can do that automatically 
and ASAP.

> If we get synchronous poison from a processor access it will be handled
> via traditional means (MCE, ARM SEA etc)

Yes.  For FW-First path, MCE mechanism can cover this.  But for OS-First 
path, errors can only be traced, then logged by userspace tool like 
rasdaemon.  We hope in OS-First path, kernel can handle it like MCE does 
too.

> 
> 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).

Yes.  In OS-First path, I think it should always be turned on.

> 
> 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.

According to kernel docs for 'early kill' of memory-failure, I think 
it's suitable for this case.

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

Agree.  Injection APIs are used for debugging, not a really HW poison.

> 
>> 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

Thanks.

> I've also dropped qemu-devel as this doesn't have anything to do with qemu.
> 

OK.

>>
>> 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?
> 
>