From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Ira Weiny <ira.weiny@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
Shiju Jose <shiju.jose@huawei.com>,
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: Tue, 19 Dec 2023 14:37:32 +0000 [thread overview]
Message-ID: <20231219143732.0000181e@Huawei.com> (raw)
In-Reply-To: <20231215-cxl-cper-v4-7-01b6dab44fcd@intel.com>
On Fri, 15 Dec 2023 15:26:33 -0800
Ira Weiny <ira.weiny@intel.com> 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>
I'd break out the pci guard stuff as a precursor patch. That's likely
to be used elsewhere so it would help for backporting for other users
if it wasn't buried in a patch doing other stuff.
Not to mention that has a different set of likely reviewers to the rest
of this patch.
More generally maybe we should just hardcode the UUID in the tracepoint
definitions? I think for everything other than the generic one we
only ever call trace_cxl_memory_module(... &mem_mod_event_uuid..)
etc.
It's a little ugly to match on the UUID to call a function where it
hard coded, but less so than inserting the UUID like this does.
Better I think to make it obvious that this isn't actually a variable
(for the ones we understand).
Jonathan
>
> ---
> NOTE this patch depends on Dan's addition of a device guard[1].
>
> [1] https://lore.kernel.org/all/170250854466.1522182.17555361077409628655.stgit@dwillia2-xfh.jf.intel.com/
>
> Changes for v3/v4:
> [djbw: define a __free(pci_dev_put) to release the device automatically]
> [djbw: use device guard from Vishal]
> [iweiny: delete old notifier block structure]
> [iweiny: adjust for new notifier interface]
> ---
> drivers/cxl/core/mbox.c | 31 +++++++++++++++++++++++-----
> drivers/cxl/cxlmem.h | 4 ++++
> drivers/cxl/pci.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/pci.h | 2 ++
> 4 files changed, 86 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> index b7efa058a100..c9aa723e3391 100644
> --- a/drivers/cxl/core/mbox.c
> +++ b/drivers/cxl/core/mbox.c
> @@ -840,9 +840,30 @@ static const uuid_t gen_media_event_uuid = CXL_EVENT_GEN_MEDIA_UUID;
> static const uuid_t dram_event_uuid = CXL_EVENT_DRAM_UUID;
> static const uuid_t mem_mod_event_uuid = CXL_EVENT_MEM_MODULE_UUID;
>
> -static void cxl_event_trace_record(const struct cxl_memdev *cxlmd,
> - enum cxl_event_log_type type,
> - struct cxl_event_record_raw *record)
> +void cxl_event_trace_record(const struct cxl_memdev *cxlmd,
> + enum cxl_event_log_type type,
> + enum cxl_event_type event_type,
> + union cxl_event *event)
> +{
> + 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;
> + }
> +}
> +EXPORT_SYMBOL_NS_GPL(cxl_event_trace_record, CXL);
> +
> +static void __cxl_event_trace_record(const struct cxl_memdev *cxlmd,
> + enum cxl_event_log_type type,
> + struct cxl_event_record_raw *record)
> {
> union cxl_event *evt = &record->event;
> uuid_t *id = &record->id;
> @@ -965,8 +986,8 @@ static void cxl_mem_get_records_log(struct cxl_memdev_state *mds,
> break;
>
> for (i = 0; i < nr_rec; i++)
> - cxl_event_trace_record(cxlmd, type,
> - &payload->records[i]);
> + __cxl_event_trace_record(cxlmd, type,
> + &payload->records[i]);
>
> if (payload->flags & CXL_GET_EVENT_FLAG_OVERFLOW)
> trace_cxl_overflow(cxlmd, type, payload);
> 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;
This is handling two conditions. I'd find it more readable split like:
if (pdev->driver != &cxl_pci_driver)
return;
cxlds = pci_get_drvdata(pdev);
if (!cxlds)
return;
and drop the = NULL above.
> +
> + /* 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);
> +}
> +
next prev parent reply other threads:[~2023-12-19 14:40 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
2023-12-19 16:58 ` Ira Weiny
2023-12-19 17:17 ` Ira Weiny
2023-12-19 14:37 ` Jonathan Cameron [this message]
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=20231219143732.0000181e@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=alison.schofield@intel.com \
--cc=ardb@kernel.org \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.