| Message ID | 20240422-cxl-cper3-v2-3-5cdd378fcd0b@intel.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | efi/cxl-cper: Report CXL CPER events through tracing | expand |
Ira Weiny wrote: > If CXL is solely managed by firmware (including HDM configuration and > event processing via firmware first) it is possible to run the system > without the CXL software loaded. In this case no CXL callback will be > loaded and CXL CPER errors will not be processed at all. > > In this case memory device and region (HPA) information is missing but > omitting the error completely is not friendly. Some device information > is available the event. > > Trace CXL CPER events if the CXL stack is not loaded. A balance was > chosen to decode only the CPER header as this configuration is likely > rare. I think the justification for this is weak and it pollutes the user ABI. What environment cares about CXL RAS without the CXL driver? If such a use case ever pops up it is trivial to revive this otherwise saves carrying this and all the minor maintenance overhead it causes.
Dan Williams wrote: > Ira Weiny wrote: > > If CXL is solely managed by firmware (including HDM configuration and > > event processing via firmware first) it is possible to run the system > > without the CXL software loaded. In this case no CXL callback will be > > loaded and CXL CPER errors will not be processed at all. > > > > In this case memory device and region (HPA) information is missing but > > omitting the error completely is not friendly. Some device information > > is available the event. > > > > Trace CXL CPER events if the CXL stack is not loaded. A balance was > > chosen to decode only the CPER header as this configuration is likely > > rare. > > I think the justification for this is weak and it pollutes the user ABI. Do you want me to drop this patch or slim the tracepoint down even further? Looking at this again I feel like 54ce1927eb78 ("cxl/cper: Fix errant CPER prints for CXL events") Was a mistake. PCI AER errors are both printed in cper_estatus_print_section() and again printed/traced in pci_print_aer() Why should CXL be any different? Ira
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index cdcfdf6ebe81..20a0e622f829 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -739,8 +739,12 @@ static void cxl_cper_post_event(enum cxl_event_type event_type, guard(spinlock_irqsave)(&cxl_cper_work_lock); - if (!cxl_cper_work) + if (!cxl_cper_work) { + union cxl_event *evt = &rec->event; + + trace_cper_cxl_event(rec, &evt->generic, event_type); return; + } wd.event_type = event_type; memcpy(&wd.rec, rec, sizeof(wd.rec)); diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h index c011ea236e9b..c1fac66fb44a 100644 --- a/include/ras/ras_event.h +++ b/include/ras/ras_event.h @@ -422,6 +422,57 @@ TRACE_EVENT(memory_failure_event, ) ); #endif /* CONFIG_MEMORY_FAILURE */ + +#include <linux/cxl-event.h> +#include <asm-generic/unaligned.h> + +TRACE_EVENT(cper_cxl_event, + + TP_PROTO(struct cxl_cper_event_rec *cper_rec, + struct cxl_event_generic *gen_rec, + enum cxl_event_type event_type), + + TP_ARGS(cper_rec, gen_rec, event_type), + + /* packed record */ + TP_STRUCT__entry( + __field(u16, segment) + __field(u8, bus) + __field(u8, device) + __field(u32, hdr_flags) + __field(u64, serial) + __field(u64, hdr_timestamp) + __field(u8, func) + __field(u8, hdr_length) + __field(u8, hdr_maint_op_class) + __field(u8, event_type) + __array(u8, data, CXL_EVENT_RECORD_DATA_LENGTH) + ), + + TP_fast_assign( + __entry->event_type = event_type; + __entry->segment = cper_rec->hdr.device_id.segment_num; + __entry->bus = cper_rec->hdr.device_id.bus_num; + __entry->device = cper_rec->hdr.device_id.device_num; + __entry->func = cper_rec->hdr.device_id.func_num; + __entry->serial = (((u64)cper_rec->hdr.dev_serial_num.upper_dw) << 32) | + cper_rec->hdr.dev_serial_num.lower_dw; + __entry->hdr_length = gen_rec->hdr.length; + __entry->hdr_flags = get_unaligned_le24(gen_rec->hdr.flags); + __entry->hdr_timestamp = le64_to_cpu(gen_rec->hdr.timestamp); + __entry->hdr_maint_op_class = gen_rec->hdr.maint_op_class; + memcpy(__entry->data, gen_rec->data, CXL_EVENT_RECORD_DATA_LENGTH); + ), + + TP_printk("device=%04x:%02x:%02x.%02x serial=%lld : event_type=%d time=%llu " + "len=%d flags=%x maint_op_class=%u : %s", + __entry->segment, __entry->bus, __entry->device, __entry->func, + __entry->serial, __entry->event_type, __entry->hdr_timestamp, + __entry->hdr_length, __entry->hdr_flags, __entry->hdr_maint_op_class, + __print_hex(__entry->data, CXL_EVENT_RECORD_DATA_LENGTH)) + +); + #endif /* _TRACE_HW_EVENT_MC_H */ /* This part must be outside protection */
If CXL is solely managed by firmware (including HDM configuration and event processing via firmware first) it is possible to run the system without the CXL software loaded. In this case no CXL callback will be loaded and CXL CPER errors will not be processed at all. In this case memory device and region (HPA) information is missing but omitting the error completely is not friendly. Some device information is available the event. Trace CXL CPER events if the CXL stack is not loaded. A balance was chosen to decode only the CPER header as this configuration is likely rare. Cc: Ard Biesheuvel <ardb@kernel.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Borislav Petkov <bp@alien8.de> Suggested-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ira Weiny <ira.weiny@intel.com> --- Changes: [djbw: remove local work task and call trace directly] [djbw: strip down the generic trace information] --- drivers/acpi/apei/ghes.c | 6 +++++- include/ras/ras_event.h | 51 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 1 deletion(-)