* Re: [PATCH 02/13] scripts/qmp_helper: add missing CXL UEFI GUID [not found] ` <f229d756fe76c34e6dfa48a98f1ee46f4325fc76.1768993993.git.mchehab+huawei@kernel.org> @ 2026-01-21 12:26 ` Jonathan Cameron 2026-01-21 15:45 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 5+ messages in thread From: Jonathan Cameron @ 2026-01-21 12:26 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Michael S Tsirkin, Shiju Jose, qemu-devel, Igor Mammedov, Cleber Rosa, John Snow, linux-cxl 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. > > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 02/13] scripts/qmp_helper: add missing CXL UEFI GUID 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 0 siblings, 1 reply; 5+ messages in thread From: Mauro Carvalho Chehab @ 2026-01-21 15:45 UTC (permalink / raw) To: Jonathan Cameron Cc: Mauro Carvalho Chehab, Michael S Tsirkin, Shiju Jose, qemu-devel, Igor Mammedov, Cleber Rosa, John Snow, linux-cxl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 02/13] scripts/qmp_helper: add missing CXL UEFI GUID 2026-01-21 15:45 ` Mauro Carvalho Chehab @ 2026-01-22 10:52 ` Jonathan Cameron 2026-01-22 15:08 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 5+ messages in thread From: Jonathan Cameron @ 2026-01-22 10:52 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Michael S Tsirkin, Shiju Jose, qemu-devel, Igor Mammedov, Cleber Rosa, John Snow, linux-cxl 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 > > > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 02/13] scripts/qmp_helper: add missing CXL UEFI GUID 2026-01-22 10:52 ` Jonathan Cameron @ 2026-01-22 15:08 ` Mauro Carvalho Chehab 2026-01-22 17:13 ` Jonathan Cameron 0 siblings, 1 reply; 5+ messages in thread From: Mauro Carvalho Chehab @ 2026-01-22 15:08 UTC (permalink / raw) To: Jonathan Cameron via qemu development Cc: Jonathan Cameron, Michael S Tsirkin, Shiju Jose, Igor Mammedov, Cleber Rosa, John Snow, linux-cxl 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]) ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 02/13] scripts/qmp_helper: add missing CXL UEFI GUID 2026-01-22 15:08 ` Mauro Carvalho Chehab @ 2026-01-22 17:13 ` Jonathan Cameron 0 siblings, 0 replies; 5+ messages in thread From: Jonathan Cameron @ 2026-01-22 17:13 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Jonathan Cameron via qemu development, Michael S Tsirkin, Shiju Jose, Igor Mammedov, Cleber Rosa, John Snow, linux-cxl, John Groves 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]) > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-01-22 17:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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
2026-01-22 17:13 ` Jonathan Cameron
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox