From: Ira Weiny <ira.weiny@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>
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>
Subject: Re: [PATCH RFC v2 3/3] cxl/memdev: Register for and process CPER events
Date: Tue, 31 Oct 2023 20:35:49 -0700 [thread overview]
Message-ID: <6541c795e39b_2e75b294e0@iweiny-mobl.notmuch> (raw)
In-Reply-To: <81b90308-fdb1-3686-33a3-1e7ec42a7ef8@amd.com>
Smita Koralahalli wrote:
> >
[snip]
> > +#define CXL_EVENT_HDR_FLAGS_REC_SEVERITY GENMASK(1, 0)
> > +int cxl_cper_event_call(struct notifier_block *nb, unsigned long action, void *data)
> > +{
> > + struct cxl_cper_notifier_data *nd = data;
> > + struct cxl_event_record_raw record = (struct cxl_event_record_raw) {
> > + .hdr.id = UUID_INIT(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0),
> > + };
> > + enum cxl_event_log_type log_type;
> > + struct cxl_memdev_state *mds;
> > + u32 hdr_flags;
> > +
> > + mds = container_of(nb, struct cxl_memdev_state, cxl_cper_nb);
> > +
> > + /* Need serial number for device identification */
> > + if (!(nd->rec->hdr.validation_bits & CPER_CXL_DEVICE_SN_VALID))
> > + return NOTIFY_DONE;
>
> For all the event records that I tested so far, this has never been
> true. That is CPER_CXL_DEVICE_SN_VALID is never set which might not log
> the records at all. Should we be bit more lenient here and include
> validating device_id (bdf) instead and check if cxlds exist?
>
> pci_get_domain_bus_and_slot() and pci_get_drvdata()..
Checking BDF is reasonable. Not sure what you mean by 'check if cxlds
exists'?
This will be called on each memdev so the cxlds should be valid. Do you
think we need some locking? I think the unregister will block device
removal if this is running.
>
> > +
> > + /* FIXME endianess and bytes of serial number need verification */
> > + /* FIXME Should other values be checked? */
> > + if (memcmp(&mds->cxlds.serial, &nd->rec->hdr.dev_serial_num,
> > + sizeof(mds->cxlds.serial)))
> > + return NOTIFY_DONE;
> > +
> > + /* ensure record can always handle the full CPER provided data */
> > + BUILD_BUG_ON(sizeof(record) <
> > + (CPER_CXL_COMP_EVENT_LOG_SIZE + sizeof(record.hdr.id)));
> > +
> > + /*
> > + * UEFI v2.10 defines N.2.14 defines the CXL CPER record as not
> > + * including the uuid field.
> > + */
> > + memcpy(&record.hdr.length, &nd->rec->comp_event_log,
> > + CPER_CXL_REC_LEN(nd->rec));
>
> I'm doubtful this will do the job.
I'm not sure why but, see below...
> I think we should copy into each
> field of struct cxl_event_record_hdr individually starting from length
> by pointer arithmetic (which is definitely bad, but I cannot think of a
> better way to do this) and then do memcpy for data field in struct
> cxl_event_record_raw..
>
> Any other suggestions would be helpful as well.
Based on Dan's suggestion to share the structures this memcpy can be
avoided altogether. Let's see how that works.
>
> I can make these changes and validate it on my end if that works..?
Any testing would be welcome. I don't have a test setup readily
available.
Ira
[snip]
next prev parent reply other threads:[~2023-11-01 3:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 18:21 [PATCH RFC v2 0/3] efi/cxl-cper: Report CPER CXL component events through trace events Ira Weiny
2023-10-26 18:21 ` [PATCH RFC v2 1/3] cxl/trace: Remove uuid from event trace known events Ira Weiny
2023-10-26 20:55 ` Dan Williams
2023-10-30 16:58 ` Davidlohr Bueso
2023-10-26 18:21 ` [PATCH RFC v2 2/3] firmware/efi: Process CXL Component Events Ira Weiny
2023-10-26 21:02 ` Dan Williams
2023-10-31 16:46 ` Ira Weiny
2023-10-26 18:21 ` [PATCH RFC v2 3/3] cxl/memdev: Register for and process CPER events Ira Weiny
2023-10-26 22:56 ` Dan Williams
2023-10-31 17:13 ` Ira Weiny
2023-11-01 17:35 ` Jonathan Cameron
2023-10-30 21:03 ` Smita Koralahalli
2023-10-30 22:02 ` Dan Williams
2023-11-01 3:35 ` Ira Weiny [this message]
2023-11-01 21:59 ` Ira Weiny
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=6541c795e39b_2e75b294e0@iweiny-mobl.notmuch \
--to=ira.weiny@intel.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=alison.schofield@intel.com \
--cc=ardb@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=jonathan.cameron@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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