Linux CXL
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Jonathan Cameron via qemu development <qemu-devel@nongnu.org>,
	"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>, John Groves <jgroves@micron.com>
Subject: Re: [PATCH 02/13] scripts/qmp_helper: add missing CXL UEFI GUID
Date: Thu, 22 Jan 2026 17:13:57 +0000	[thread overview]
Message-ID: <20260122171357.00000747@huawei.com> (raw)
In-Reply-To: <20260122160809.0a3acbb8@localhost>

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


      reply	other threads:[~2026-01-22 17:14 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
2026-01-22 17:13           ` Jonathan Cameron [this message]

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=20260122171357.00000747@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=crosa@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jgroves@micron.com \
    --cc=jsnow@redhat.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=mchehab+huawei@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