The UEFI 2.11 - N.2.14. CXL Component Events Section states that
XL events are described at CXL specification 3.2:
8.2.10.2.1 Event Records
Add the GUIDs defined here to fuzzy logic error injection code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
scripts/qmp_helper.py | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/scripts/qmp_helper.py b/scripts/qmp_helper.py
index 249a8c7187d1..7e786c4adfd9 100755
--- a/scripts/qmp_helper.py
+++ b/scripts/qmp_helper.py
@@ -711,3 +711,28 @@ class cper_guid:
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])
+ CPER_CXL_EVT_DRAM = guid(0x601DCBB3, 0x9C06, 0x4EAB,
+ [0xB8, 0xAF, 0x4E, 0x9B,
+ 0xFB, 0x5C, 0x96, 0x24])
+ CPER_CXL_EVT_MEM_MODULE = guid(0xFE927475, 0xDD59, 0x4339,
+ [0xA5, 0x86, 0x79, 0xBA,
+ 0xB1, 0x13, 0xBC, 0x74])
+ CPER_CXL_EVT_MEM_SPARING = guid(0xE71F3A40, 0x2D29, 0x4092,
+ [0x8A, 0x39, 0x4D, 0x1C,
+ 0x96, 0x6C, 0x7C, 0x65])
+ CPER_CXL_EVT_PHY_SW = guid(0x77CF9271, 0x9C02, 0x470B,
+ [0x9F, 0xE4, 0xBC, 0x7B,
+ 0x75, 0xF2, 0xDA, 0x97])
+ CPER_CXL_EVT_VIRT_SW = guid(0x40D26425, 0x3396, 0x4C4D,
+ [0xA5, 0xDA, 0x3D, 0x47,
+ 0x2A, 0x63, 0xAF, 0x25])
+ CPER_CXL_EVT_MLD_PORT = guid(0x8DC44363, 0x0C96, 0x4710,
+ [0xB7, 0xBF, 0x04, 0xBB,
+ 0x99, 0x53, 0x4C, 0x3F])
+ CPER_CXL_EVT_DYNA_CAP = guid(0xCA95AFA7, 0xF183, 0x4018,
+ [0x8C, 0x2F, 0x95, 0x26,
+ 0x8E, 0x10, 0x1A, 0x2A])
--
2.52.0On 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. > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> > --- > scripts/qmp_helper.py | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/scripts/qmp_helper.py b/scripts/qmp_helper.py > index 249a8c7187d1..7e786c4adfd9 100755 > --- a/scripts/qmp_helper.py > +++ b/scripts/qmp_helper.py > @@ -711,3 +711,28 @@ class cper_guid: > 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]) > + CPER_CXL_EVT_DRAM = guid(0x601DCBB3, 0x9C06, 0x4EAB, > + [0xB8, 0xAF, 0x4E, 0x9B, > + 0xFB, 0x5C, 0x96, 0x24]) > + CPER_CXL_EVT_MEM_MODULE = guid(0xFE927475, 0xDD59, 0x4339, > + [0xA5, 0x86, 0x79, 0xBA, > + 0xB1, 0x13, 0xBC, 0x74]) > + CPER_CXL_EVT_MEM_SPARING = guid(0xE71F3A40, 0x2D29, 0x4092, > + [0x8A, 0x39, 0x4D, 0x1C, > + 0x96, 0x6C, 0x7C, 0x65]) The above are all fine I think. From here on I think they will never come via a CPER record. > + CPER_CXL_EVT_PHY_SW = guid(0x77CF9271, 0x9C02, 0x470B, > + [0x9F, 0xE4, 0xBC, 0x7B, > + 0x75, 0xF2, 0xDA, 0x97]) This is only going to surface over either out of band or switch CCI I'd be very surprised to see a firmware anywhere near these. More specifically they are only defined in the Fabric management section of the spec, which strongly hints we'd not expect host firmware to know anything about them. The events reported may well span bits of the topology currently assigned to different hosts. > + CPER_CXL_EVT_VIRT_SW = guid(0x40D26425, 0x3396, 0x4C4D, > + [0xA5, 0xDA, 0x3D, 0x47, > + 0x2A, 0x63, 0xAF, 0x25]) Also a fabric management event. > + CPER_CXL_EVT_MLD_PORT = guid(0x8DC44363, 0x0C96, 0x4710, > + [0xB7, 0xBF, 0x04, 0xBB, > + 0x99, 0x53, 0x4C, 0x3F]) Also a fabric management event. > + CPER_CXL_EVT_DYNA_CAP = guid(0xCA95AFA7, 0xF183, 0x4018, > + [0x8C, 0x2F, 0x95, 0x26, > + 0x8E, 0x10, 0x1A, 0x2A]) These are never routed to firmware. They are part of the OS only managed flows for dynamic capacity. They have their own event log on the hardware and for this particular set most relevant thing is in CXL 4.0 Table 8-235 Set Event Interrupt Policy Input Payload which controls whether a firmware interrupt or MSIX is used signal the Dynamic Capacity Event Log Interrupt Settings only allows for MSI/MSI-X, not FW interrupt (EFN VDM) like the other logs. Jonathan
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.
>
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---
> > scripts/qmp_helper.py | 25 +++++++++++++++++++++++++
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/scripts/qmp_helper.py b/scripts/qmp_helper.py
> > index 249a8c7187d1..7e786c4adfd9 100755
> > --- a/scripts/qmp_helper.py
> > +++ b/scripts/qmp_helper.py
> > @@ -711,3 +711,28 @@ class cper_guid:
> > 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])
> > + CPER_CXL_EVT_DRAM = guid(0x601DCBB3, 0x9C06, 0x4EAB,
> > + [0xB8, 0xAF, 0x4E, 0x9B,
> > + 0xFB, 0x5C, 0x96, 0x24])
> > + CPER_CXL_EVT_MEM_MODULE = guid(0xFE927475, 0xDD59, 0x4339,
> > + [0xA5, 0x86, 0x79, 0xBA,
> > + 0xB1, 0x13, 0xBC, 0x74])
> > + CPER_CXL_EVT_MEM_SPARING = guid(0xE71F3A40, 0x2D29, 0x4092,
> > + [0x8A, 0x39, 0x4D, 0x1C,
> > + 0x96, 0x6C, 0x7C, 0x65])
>
> The above are all fine I think.
>
> From here on I think they will never come via a CPER record.
>
> > + CPER_CXL_EVT_PHY_SW = guid(0x77CF9271, 0x9C02, 0x470B,
> > + [0x9F, 0xE4, 0xBC, 0x7B,
> > + 0x75, 0xF2, 0xDA, 0x97])
>
> This is only going to surface over either out of band or switch CCI
> I'd be very surprised to see a firmware anywhere near these.
> More specifically they are only defined in the Fabric management
> section of the spec, which strongly hints we'd not expect host firmware
> to know anything about them.
> The events reported may well span bits of the topology currently
> assigned to different hosts.
>
> > + CPER_CXL_EVT_VIRT_SW = guid(0x40D26425, 0x3396, 0x4C4D,
> > + [0xA5, 0xDA, 0x3D, 0x47,
> > + 0x2A, 0x63, 0xAF, 0x25])
>
> Also a fabric management event.
>
> > + CPER_CXL_EVT_MLD_PORT = guid(0x8DC44363, 0x0C96, 0x4710,
> > + [0xB7, 0xBF, 0x04, 0xBB,
> > + 0x99, 0x53, 0x4C, 0x3F])
>
> Also a fabric management event.
>
> > + CPER_CXL_EVT_DYNA_CAP = guid(0xCA95AFA7, 0xF183, 0x4018,
> > + [0x8C, 0x2F, 0x95, 0x26,
> > + 0x8E, 0x10, 0x1A, 0x2A])
> These are never routed to firmware. They are part of the OS only
> managed flows for dynamic capacity.
> They have their own event log on the hardware and for this particular
> set most relevant thing is in
> CXL 4.0 Table 8-235 Set Event Interrupt Policy Input Payload
> which controls whether a firmware interrupt or MSIX is used signal
> the Dynamic Capacity Event Log Interrupt Settings only allows
> for MSI/MSI-X, not FW interrupt (EFN VDM) like the other logs.
>
>
> Jonathan
>
>
--
Thanks,
Mauro
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. > > > > > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> > > > --- > > > scripts/qmp_helper.py | 25 +++++++++++++++++++++++++ > > > 1 file changed, 25 insertions(+) > > > > > > diff --git a/scripts/qmp_helper.py b/scripts/qmp_helper.py > > > index 249a8c7187d1..7e786c4adfd9 100755 > > > --- a/scripts/qmp_helper.py > > > +++ b/scripts/qmp_helper.py > > > @@ -711,3 +711,28 @@ class cper_guid: > > > 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]) > > > + CPER_CXL_EVT_DRAM = guid(0x601DCBB3, 0x9C06, 0x4EAB, > > > + [0xB8, 0xAF, 0x4E, 0x9B, > > > + 0xFB, 0x5C, 0x96, 0x24]) > > > + CPER_CXL_EVT_MEM_MODULE = guid(0xFE927475, 0xDD59, 0x4339, > > > + [0xA5, 0x86, 0x79, 0xBA, > > > + 0xB1, 0x13, 0xBC, 0x74]) > > > + CPER_CXL_EVT_MEM_SPARING = guid(0xE71F3A40, 0x2D29, 0x4092, > > > + [0x8A, 0x39, 0x4D, 0x1C, > > > + 0x96, 0x6C, 0x7C, 0x65]) > > > > The above are all fine I think. > > > > From here on I think they will never come via a CPER record. > > > > > + CPER_CXL_EVT_PHY_SW = guid(0x77CF9271, 0x9C02, 0x470B, > > > + [0x9F, 0xE4, 0xBC, 0x7B, > > > + 0x75, 0xF2, 0xDA, 0x97]) > > > > This is only going to surface over either out of band or switch CCI > > I'd be very surprised to see a firmware anywhere near these. > > More specifically they are only defined in the Fabric management > > section of the spec, which strongly hints we'd not expect host firmware > > to know anything about them. > > The events reported may well span bits of the topology currently > > assigned to different hosts. > > > > > + CPER_CXL_EVT_VIRT_SW = guid(0x40D26425, 0x3396, 0x4C4D, > > > + [0xA5, 0xDA, 0x3D, 0x47, > > > + 0x2A, 0x63, 0xAF, 0x25]) > > > > Also a fabric management event. > > > > > + CPER_CXL_EVT_MLD_PORT = guid(0x8DC44363, 0x0C96, 0x4710, > > > + [0xB7, 0xBF, 0x04, 0xBB, > > > + 0x99, 0x53, 0x4C, 0x3F]) > > > > Also a fabric management event. > > > > > + CPER_CXL_EVT_DYNA_CAP = guid(0xCA95AFA7, 0xF183, 0x4018, > > > + [0x8C, 0x2F, 0x95, 0x26, > > > + 0x8E, 0x10, 0x1A, 0x2A]) > > These are never routed to firmware. They are part of the OS only > > managed flows for dynamic capacity. > > They have their own event log on the hardware and for this particular > > set most relevant thing is in > > CXL 4.0 Table 8-235 Set Event Interrupt Policy Input Payload > > which controls whether a firmware interrupt or MSIX is used signal > > the Dynamic Capacity Event Log Interrupt Settings only allows > > for MSI/MSI-X, not FW interrupt (EFN VDM) like the other logs. > > > > > > Jonathan > > > > >
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])
On Thu, 22 Jan 2026 16:08:09 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> 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.
>
Fair point. Some of those we shouldn't see at a host. Something to tidy up
in the spec.
+CC John Groves to make it his problem ;)
Dynamic Capacity events go to the host (well some of the them anyway),
but never to firmware, so there is blurry boundary.
Some values of the Event type for those state they are not sent to the host.
"This event shall only be reported to the FM".
J
> 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])
>
>
>
© 2016 - 2026 Red Hat, Inc.