在 2024/8/27 23:46, Jonathan Cameron 写道:
On Thu, 8 Aug 2024 23:13:27 +0800
Shiyang Ruan <ruansy.fnst@xxxxxxxxxxx> 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@xxxxxxxxxxx>
Experienced RAS folk in the CC, how do you want this to work for
asynchoronous memory errors on CXL devices?
