> +
> +void cxl_event_handle_record(struct cxl_memdev *cxlmd,
> + enum cxl_event_log_type type,
> + enum cxl_event_type event_type,
> + const uuid_t *uuid, union cxl_event *evt)
> +{
> + if (event_type == CXL_CPER_EVENT_GEN_MEDIA) {
> trace_cxl_general_media(cxlmd, type, &evt->gen_media);
> - else if (event_type == CXL_CPER_EVENT_DRAM)
> + /* handle poison event */
> + if (type == CXL_EVENT_TYPE_FAIL)
> + cxl_event_handle_poison(cxlmd, &evt->gen_media);
I'm not 100% convinced this is necessary poison causing. Also
the text tells us we should see 'an appropriate event'.
DRAM one seems likely to be chosen by some vendors.
The fatal check maybe makes it a little more likely (maybe though
I'm not sure anything says a device must log it to the failure log)
but it might be Memory Event Type 1, which is the host tried to
access an invalid address. Sure poison might be returned to that
error but what would the main kernel memory handling do with it?
Something is very wrong
but it's not corrupted device memory. TE state violations are in there
as well. Sure poison is returned on reads (I think - haven't checked).
IF the aim here is to say 'maybe there is poison, better check the
poison list'. Then that is reasonable but we should ensure things
like timer expiry are definitely ruled out and rename the function
to make it clear it might not find poison.
Jonathan
