From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jonathan Cameron via qemu development <qemu-devel@nongnu.org>
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>,
Michael S Tsirkin <mst@redhat.com>,
Shiju Jose <shiju.jose@huawei.com>,
Igor Mammedov <imammedo@redhat.com>,
Cleber Rosa <crosa@redhat.com>, John Snow <jsnow@redhat.com>,
<linux-cxl@vger.kernel.org>
Subject: Re: [PATCH 02/13] scripts/qmp_helper: add missing CXL UEFI GUID
Date: Thu, 22 Jan 2026 16:08:09 +0100 [thread overview]
Message-ID: <20260122160809.0a3acbb8@localhost> (raw)
In-Reply-To: <20260122105214.00001cca@huawei.com>
On Thu, 22 Jan 2026 10:52:14 +0000
Jonathan Cameron via qemu development <qemu-devel@nongnu.org> wrote:
> On Wed, 21 Jan 2026 16:45:58 +0100
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>
> > On Wed, Jan 21, 2026 at 12:26:04PM +0000, Jonathan Cameron wrote:
> > > On Wed, 21 Jan 2026 12:25:10 +0100
> > > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> > >
> > > > The UEFI 2.11 - N.2.14. CXL Component Events Section states that
> > > > XL events are described at CXL specification 3.2:
> > > CXL
> > >
> > > > 8.2.10.2.1 Event Records
> > > >
> > > > Add the GUIDs defined here to fuzzy logic error injection code.
> > >
> > > +CC linux-cxl as more folk there who will be familiar with this
> > > stuff.
> > >
> > > Some of these won't be seen on a host. The same event
> > > infrastructure is used for reporting on out of band interfaces
> > > and some in band ones, but not ones that will turn up on the
> > > mailboxes that firmware will be using to get info.
> >
> > Good to know, but UEFI 2.11 still mentions all of them as
> > possible GUIDs:
> >
> > https://uefi.org/specs/UEFI/2.11/Apx_N_Common_Platform_Error_Record.html#cxl-component-events-section
> >
> > So, the UEFI 2.11 doesn't explicitly state they won't de delivered
> > to OSPM. Quite contrary, they're listed as valid values for CPER,
> > even if, in practice, they won't.
> >
> > This is just a small set of variables, that won't bring any major
> > impact on the code. So, I prefer to keep them in sync with the spec.
> > If they end removing the unused ones, we can update it in the future.
> >
> > If you want, I can add a note at the next version with your
> > comments about them.
> >
> A note works for me.
>
> As I understand it CPER records are getting adopted in other specs
> so it may make sense to document them, even if they aren't a possibility
> via ACPI.
>
> However I'm not seeing them in the spec link you point at.
> All I'm seeing is a cross reference the CXL spec Events Record Format.
Heh, true, I got confused with another field. Yet, at CXL spec 3.2,
it is said that:
8.2.10.2 Events
===============
This section defines the standard event record format that all CXL devices shall use
when reporting events to the host.
...
Table 8-55. Common Event Record Format (Sheet 1 of 2)
------ -------- ----------------------------------------------------------------------------
Byte Length Description
Offset in Bytes
------ -------- ----------------------------------------------------------------------------
00h 10h Event Record Identifier: UUID representing the specific Event Record format.
The following UUIDs are defined in this spec:
• fbcd0a77-c260-417f-85a9-088b1621eba6 – General Media Event Record
(see Table 8-57)
• 601dcbb3-9c06-4eab-b8af-4e9bfb5c9624 – DRAM Event Record (see
Table 8-58)
• fe927475-dd59-4339-a586-79bab113b774 – Memory Module Event Record
(see Table 8-59)
• e71f3a40-2d29-4092-8a39-4d1c966c7c65 - Memory Sparing Event Record
(see Table 8-60)
• 77cf9271-9c02-470b-9fe4-bc7b75f2da97 – Physical Switch Event Record
(see Table 7-77)
• 40d26425-3396-4c4d-a5da-3d47263af425 – Virtual Switch Event Record
(see Table 7-78)
• 8dc44363-0c96-4710-b7bf-04bb99534c3f – MLD Port Event Record (see
Table 7-79)
• ca95afa7-f183-4018-8c2f-95268e101a2a - Dynamic Capacity Event Record
(see Table 8-62)
------ -------- ----------------------------------------------------------------------------
...
So, CXL specs say they'll arrive at the host, and UEFI doesn't tell
they can't arrive the OSPM.
In any case, it is easier to just pick the entire set with 8 GUIDs
and keep the scripts in sync with the specs than filtering what
shouldn't belong there and why, with the risk of eventually miss
something.
I'll append the diff below to the relevant patches on this patchset.
Regards,
Mauro
---
diff --git a/scripts/ghes_decode.py b/scripts/ghes_decode.py
index 6c7fdfe84e3a..7bac7dbd6b3a 100644
--- a/scripts/ghes_decode.py
+++ b/scripts/ghes_decode.py
@@ -935,6 +935,10 @@ class DecodeCXLCompEvent():
"""
# GUIDs, as defined at CXL specification 3.2: 8.2.10.2.1 Event Records
+ # on Table 8-55. Common Event Record Format
+ #
+ # Please notice that, in practice, not all those events will be passed
+ # to OSPM. Some may be handled internally.
guids = [
("General Media", "fbcd0a77-c260-417f-85a9-088b1621eba6"),
("DRAM", "601dcbb3-9c06-4eab-b8af-4e9bfb5c9624"),
diff --git a/scripts/qmp_helper.py b/scripts/qmp_helper.py
index 32baca17ce10..583f898f04ef 100755
--- a/scripts/qmp_helper.py
+++ b/scripts/qmp_helper.py
@@ -778,10 +778,14 @@ class cper_guid:
[0xA6, 0xA6, 0x88, 0xB7,
0x28, 0xCF, 0x75, 0xD7])
+ # CXL GUIDs, as defined at CXL specification 3.2: 8.2.10.2.1 Event Records
+ # on Table 8-55. Common Event Record Format
+ #
+ # Please notice that, in practice, not all those events will be passed
+ # to OSPM. Some may be consumed internally
CPER_CXL_PROT_ERR = guid(0x80B9EFB4, 0x52B5, 0x4DE3,
[0xA7, 0x77, 0x68, 0x78,
0x4B, 0x77, 0x10, 0x48])
-
CPER_CXL_EVT_GEN_MEDIA = guid(0xFBCD0A77, 0xC260, 0x417F,
[0x85, 0xA9, 0x08, 0x8B,
0x16, 0x21, 0xEB, 0xA6])
next prev parent reply other threads:[~2026-01-22 15:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1768993993.git.mchehab+huawei@kernel.org>
[not found] ` <f229d756fe76c34e6dfa48a98f1ee46f4325fc76.1768993993.git.mchehab+huawei@kernel.org>
2026-01-21 12:26 ` [PATCH 02/13] scripts/qmp_helper: add missing CXL UEFI GUID Jonathan Cameron
2026-01-21 15:45 ` Mauro Carvalho Chehab
2026-01-22 10:52 ` Jonathan Cameron
2026-01-22 15:08 ` Mauro Carvalho Chehab [this message]
2026-01-22 17:13 ` 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=20260122160809.0a3acbb8@localhost \
--to=mchehab+huawei@kernel.org \
--cc=crosa@redhat.com \
--cc=imammedo@redhat.com \
--cc=jonathan.cameron@huawei.com \
--cc=jsnow@redhat.com \
--cc=linux-cxl@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=shiju.jose@huawei.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