Re: [PATCH 02/13] scripts/qmp_helper: add missing CXL UEFI GUID

[Jonathan Cameron <jonathan.cameron@huawei.com>]

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
> > 
> >   
>