edac fixes for v6.10-rc6
RAS: Report all ARM processor CPER information to userspace
The ARM processor CPER record was added at UEFI 2.6, and hasn't
any changes up to UEFI 2.10 on its struct.
Yet, the original arm_event trace code added on changeset
e9279e83ad1f ("trace, ras: add ARM processor error trace event") is
incomplete, as it only traces some fields of UAPI 2.6 table N.16,
not exporting at all any information from tables N.17 to N.29 of
the record.
This is not enough for user to take appropriate action or to log
what exactly happened.
According to UEFI_2_9 specification chapter N2.4.4, the ARM processor
error section includes:
- several (ERR_INFO_NUM) ARM processor error information structures
(Tables N.17 to N.20);
- several (CONTEXT_INFO_NUM) ARM processor context information
structures (Tables N.21 to N.29);
- several vendor specific error information structures. The
size is given by Section Length minus the size of the other
fields.
In addition to those data, it also exports two fields that are
parsed by the GHES driver when firmware reports it, e. g.:
- error severity
- cpu logical index
Report all of these information to userspace via trace uAPI, So that
userspace can properly record the error and take decisions related
to cpu core isolation according to error severity and other info.
After this patch, all the data from ARM Processor record from table
N.16 is sent to userspace:
====================================== =============================
UEFI field on table N.16 ARM Processor trace event
====================================== =============================
Validation handled when filling data for
affinity MPIDR and running
state.
ERR_INFO_NUM pei_len field
CONTEXT_INFO_NUM ctx_len field
Section Length indirectly reported when
handling vendor-specific data
size
Error affinity level affinity
MPIDR_EL1 mpidr field
MIDR_EL1 midr field
Running State running_state field
PSCI State psci_state field
Processor Error Information Structure reported as hex values via
__print_hex()
Processor Context reported as hex values via
__print_hex()
Vendor Specific Error Info reported as hex values via
__print_hex()
====================================== =============================
It should be noticed that decoding of tables N.17 to N.29, if needed,
will be handled on userspace. That gives more flexibility, as there
won't be any need to flood the Kernel with micro-architecture specific
error decoding (as found at vendor-specific field of the record).
Also, decoding the other fields require a complex logic, and should
be done for each of the several values inside the record field.
So, let userspace daemons like rasdaemon to decode them, parsing such
tables and having vendor-specific micro-architecture-specific decoders.
Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-section
Fixes: e9279e83ad1f ("trace, ras: add ARM processor error trace event")
[mchehab: modified the description to properly describe the change]
Signed-off-by: Shengwei Luo <luoshengwei@huawei.com>
Signed-off-by: Jason Tian <jason@os.amperecomputing.com>
Signed-off-by: Daniel Ferguson <danielf@os.amperecomputing.com>
Tested-by: Shiju Jose <shiju.jose@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 files changed
