Linux CXL
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Michael S Tsirkin <mst@redhat.com>,
	Shiju Jose <shiju.jose@huawei.com>, <qemu-devel@nongnu.org>,
	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: Wed, 21 Jan 2026 12:26:04 +0000	[thread overview]
Message-ID: <20260121122604.00001609@huawei.com> (raw)
In-Reply-To: <f229d756fe76c34e6dfa48a98f1ee46f4325fc76.1768993993.git.mchehab+huawei@kernel.org>

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



       reply	other threads:[~2026-01-21 12:26 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   ` Jonathan Cameron [this message]
2026-01-21 15:45     ` [PATCH 02/13] scripts/qmp_helper: add missing CXL UEFI GUID 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

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=20260121122604.00001609@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=crosa@redhat.com \
    --cc=imammedo@redhat.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