From: Dan Williams <dan.j.williams@intel.com>
To: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
Ira Weiny <ira.weiny@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
"Jonathan Cameron" <jonathan.cameron@huawei.com>,
Shiju Jose <shiju.jose@huawei.com>
Cc: Yazen Ghannam <yazen.ghannam@amd.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Dave Jiang <dave.jiang@intel.com>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
"Ard Biesheuvel" <ardb@kernel.org>, <linux-efi@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v4 7/7] cxl/memdev: Register for and process CPER events
Date: Mon, 18 Dec 2023 12:56:55 -0800 [thread overview]
Message-ID: <6580b21723b2c_269bd294f8@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <4cb5c275-566c-9414-7088-1e91378a409a@amd.com>
Smita Koralahalli wrote:
> On 12/15/2023 3:26 PM, Ira Weiny wrote:
> > If the firmware has configured CXL event support to be firmware first
> > the OS can process those events through CPER records. The CXL layer has
> > unique DPA to HPA knowledge and standard event trace parsing in place.
> >
> > CPER records contain Bus, Device, Function information which can be used
> > to identify the PCI device which is sending the event.
> >
> > Change pci driver registration to include registration for a CXL CPER
> > notifier to process the events through the trace subsystem.
> >
> > Define and use scoped based management to simplify the handling of the
> > pci device object.
> >
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> >
> > ---
>
> [snip]
>
>
> > + switch (event_type) {
> > + case CXL_CPER_EVENT_GEN_MEDIA:
> > + trace_cxl_general_media(cxlmd, type, &gen_media_event_uuid,
> > + &event->gen_media);
> > + break;
> > + case CXL_CPER_EVENT_DRAM:
> > + trace_cxl_dram(cxlmd, type, &dram_event_uuid, &event->dram);
> > + break;
> > + case CXL_CPER_EVENT_MEM_MODULE:
> > + trace_cxl_memory_module(cxlmd, type, &mem_mod_event_uuid,
> > + &event->mem_module);
> > + break;
> > + }
> > +}
>
> Is default case needed here?
Yeah, it looks like an uninitialized @type value can be passed through
the stack here.
[..]
> > diff --git a/drivers/cxl/pci.c b/drivers/cxl/pci.c
> > index 0155fb66b580..638275569d63 100644
> > --- a/drivers/cxl/pci.c
> > +++ b/drivers/cxl/pci.c
> > @@ -1,5 +1,6 @@
> > // SPDX-License-Identifier: GPL-2.0-only
> > /* Copyright(c) 2020 Intel Corporation. All rights reserved. */
> > +#include <asm-generic/unaligned.h>
> > #include <linux/io-64-nonatomic-lo-hi.h>
> > #include <linux/moduleparam.h>
> > #include <linux/module.h>
> > @@ -969,6 +970,58 @@ static struct pci_driver cxl_pci_driver = {
> > },
> > };
> >
> > +#define CXL_EVENT_HDR_FLAGS_REC_SEVERITY GENMASK(1, 0)
> > +static void cxl_cper_event_call(enum cxl_event_type ev_type,
> > + struct cxl_cper_event_rec *rec)
> > +{
> > + struct cper_cxl_event_devid *device_id = &rec->hdr.device_id;
> > + struct pci_dev *pdev __free(pci_dev_put) = NULL;
> > + struct cxl_dev_state *cxlds = NULL;
> > + enum cxl_event_log_type log_type;
> > + unsigned int devfn;
> > + u32 hdr_flags;
> > +
> > + devfn = PCI_DEVFN(device_id->device_num, device_id->func_num);
> > + pdev = pci_get_domain_bus_and_slot(device_id->segment_num,
> > + device_id->bus_num, devfn);
> > + if (!pdev)
> > + return;
> > +
> > + guard(device)(&pdev->dev);
> > + if (pdev->driver == &cxl_pci_driver)
> > + cxlds = pci_get_drvdata(pdev);
> > + if (!cxlds)
> > + return;
> > +
> > + /* Fabricate a log type */
> > + hdr_flags = get_unaligned_le24(rec->event.generic.hdr.flags);
> > + log_type = FIELD_GET(CXL_EVENT_HDR_FLAGS_REC_SEVERITY, hdr_flags);
> > +
> > + cxl_event_trace_record(cxlds->cxlmd, log_type, ev_type, &rec->event);
>
> Currently, when I run this, I see two trace events printed. One from
> here, and another as a non_standard_event from ghes. I think both should
> be unified?
>
> I remember Dan pointing out to me this when I sent decoding for protocol
> errors and its still pending on me for protocol errors.
Good point, so I think the responsibility to trace CXL events should
belong to ghes_do_proc() and ghes_print_estatus() can just ignore CXL
events.
Notice how ghes_proc() sometimes skips ghes_print_estatus(), but
uncoditionally emits a trace event in ghes_do_proc()? To me that means
that the cper_estatus_print() inside ghes_print_estatus() can just defer
to the ghes code to do the hookup to the trace code.
For example, ras_userspace_consumers() was introduced to skip emitting
events to the kernel log when the trace event might be handled. My
assumption is that was for historical reasons, but since CXL events are
new, just never emit them to the kernel log and always require the trace
path.
I am open to other thoughts here, but it seems like ghes_do_proc() is
where the callback needs to be triggered.
> Thanks,
> Smita
>
> > +}
> > +
> > +static int __init cxl_pci_driver_init(void)
> > +{
> > + int rc;
> > +
> > + rc = pci_register_driver(&cxl_pci_driver);
> > + if (rc)
> > + return rc;
> > +
> > + rc = cxl_cper_register_notifier(cxl_cper_event_call);
Quick aside as I am reading through this, the "notifier" name is
misleading since this callback has nothing to do with the
include/linux/notifier.h API.
next prev parent reply other threads:[~2023-12-18 20:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 23:26 [PATCH v4 0/7] efi/cxl-cper: Report CPER CXL component events through trace events Ira Weiny
2023-12-15 23:26 ` [PATCH v4 1/7] cxl/trace: Pass uuid explicitly to event traces Ira Weiny
2023-12-15 23:26 ` [PATCH v4 2/7] cxl/events: Promote CXL event structures to a core header Ira Weiny
2023-12-15 23:26 ` [PATCH v4 3/7] cxl/events: Create common event UUID defines Ira Weiny
2023-12-15 23:26 ` [PATCH v4 4/7] cxl/events: Separate UUID from event structures Ira Weiny
2023-12-15 23:26 ` [PATCH v4 5/7] cxl/events: Create a CXL event union Ira Weiny
2023-12-15 23:26 ` [PATCH v4 6/7] firmware/efi: Process CXL Component Events Ira Weiny
2023-12-18 18:13 ` Smita Koralahalli
2023-12-18 20:24 ` Dan Williams
2023-12-19 15:43 ` Ira Weiny
2023-12-19 14:24 ` Jonathan Cameron
2023-12-19 18:01 ` Ira Weiny
2023-12-15 23:26 ` [PATCH v4 7/7] cxl/memdev: Register for and process CPER events Ira Weiny
2023-12-18 18:17 ` Smita Koralahalli
2023-12-18 20:56 ` Dan Williams [this message]
2023-12-19 16:58 ` Ira Weiny
2023-12-19 17:17 ` Ira Weiny
2023-12-19 14:37 ` Jonathan Cameron
2023-12-19 23:27 ` Ira Weiny
2023-12-19 23:36 ` Dan Williams
2023-12-20 0:29 ` Ira Weiny
2024-01-03 10:41 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6580b21723b2c_269bd294f8@dwillia2-mobl3.amr.corp.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=alison.schofield@intel.com \
--cc=ardb@kernel.org \
--cc=bhelgaas@google.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shiju.jose@huawei.com \
--cc=vishal.l.verma@intel.com \
--cc=yazen.ghannam@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox