From: Shiju Jose <shiju.jose@huawei.com>
CXL spec rev3.2 section 8.2.10.2.1.3 Table 8-50, memory module
event record has updated with following new fields.
1. Validity Flags
2. Component Identifier
3. Device Event Sub-Type
Add updates for the above spec changes in the CXL memory module
event reporting and QMP command to inject memory module event.
Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
qapi/cxl.json | 12 +++++++++++-
include/hw/cxl/cxl_events.h | 7 +++++--
hw/mem/cxl_type3.c | 20 ++++++++++++++++++++
hw/mem/cxl_type3_stubs.c | 4 ++++
4 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/qapi/cxl.json b/qapi/cxl.json
index 3e4bad4ad0..752d46cda2 100644
--- a/qapi/cxl.json
+++ b/qapi/cxl.json
@@ -242,6 +242,14 @@
# @corrected-persistent-error-count: Total number of correctable
# errors in persistent memory
#
+# @component-id: Device specific component identifier for the event.
+# May describe a field replaceable sub-component of the device.
+#
+# @is-comp-id-pldm: This flag specifies whether the device-specific
+# component identifier format follows PLDM.
+#
+# @sub-type: Device event sub-type.
+#
# Since: 8.1
##
{ 'struct': 'CXLMemModuleEvent',
@@ -251,7 +259,9 @@
'life-used': 'uint8', 'temperature' : 'int16',
'dirty-shutdown-count': 'uint32',
'corrected-volatile-error-count': 'uint32',
- 'corrected-persistent-error-count': 'uint32'
+ 'corrected-persistent-error-count': 'uint32',
+ '*component-id': 'str', '*is-comp-id-pldm':'bool',
+ 'sub-type':'uint8'
}}
##
diff --git a/include/hw/cxl/cxl_events.h b/include/hw/cxl/cxl_events.h
index a3c5f2ec20..4a7836ad72 100644
--- a/include/hw/cxl/cxl_events.h
+++ b/include/hw/cxl/cxl_events.h
@@ -166,7 +166,7 @@ typedef struct CXLEventDram {
/*
* Memory Module Event Record
- * CXL r3.1 Section 8.2.9.2.1.3: Table 8-47
+ * CXL r3.2 Section 8.2.10.2.1.3: Table 8-59
* All fields little endian.
*/
typedef struct CXLEventMemoryModule {
@@ -180,7 +180,10 @@ typedef struct CXLEventMemoryModule {
uint32_t dirty_shutdown_count;
uint32_t corrected_volatile_error_count;
uint32_t corrected_persistent_error_count;
- uint8_t reserved[0x3d];
+ uint16_t validity_flags;
+ uint8_t component_id[CXL_EVENT_GEN_MED_COMP_ID_SIZE];
+ uint8_t sub_type;
+ uint8_t reserved[0x2a];
} QEMU_PACKED CXLEventMemoryModule;
/*
diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
index 3da538bafb..4dc9b223f4 100644
--- a/hw/mem/cxl_type3.c
+++ b/hw/mem/cxl_type3.c
@@ -1937,6 +1937,9 @@ void qmp_cxl_inject_dram_event(const char *path, CxlEventLog log,
}
}
+#define CXL_MMER_VALID_COMPONENT BIT(0)
+#define CXL_MMER_VALID_COMPONENT_ID_FORMAT BIT(1)
+
void qmp_cxl_inject_memory_module_event(const char *path, CxlEventLog log,
uint32_t flags, bool has_maint_op_class,
uint8_t maint_op_class,
@@ -1953,11 +1956,16 @@ void qmp_cxl_inject_memory_module_event(const char *path, CxlEventLog log,
uint32_t dirty_shutdown_count,
uint32_t corrected_volatile_error_count,
uint32_t corrected_persist_error_count,
+ const char *component_id,
+ bool has_comp_id_pldm,
+ bool is_comp_id_pldm,
+ uint8_t sub_type,
Error **errp)
{
Object *obj = object_resolve_path(path, NULL);
CXLEventMemoryModule module;
CXLEventRecordHdr *hdr = &module.hdr;
+ uint16_t valid_flags = 0;
CXLDeviceState *cxlds;
CXLType3Dev *ct3d;
uint8_t enc_log;
@@ -2000,6 +2008,18 @@ void qmp_cxl_inject_memory_module_event(const char *path, CxlEventLog log,
stl_le_p(&module.corrected_persistent_error_count,
corrected_persist_error_count);
+ if (component_id) {
+ strncpy((char *)module.component_id, component_id,
+ sizeof(module.component_id) - 1);
+ valid_flags |= CXL_MMER_VALID_COMPONENT;
+ if (has_comp_id_pldm && is_comp_id_pldm) {
+ valid_flags |= CXL_MMER_VALID_COMPONENT_ID_FORMAT;
+ }
+ }
+ module.sub_type = sub_type;
+
+ stw_le_p(&module.validity_flags, valid_flags);
+
if (cxl_event_insert(cxlds, enc_log, (CXLEventRecordRaw *)&module)) {
cxl_event_irq_assert(ct3d);
}
diff --git a/hw/mem/cxl_type3_stubs.c b/hw/mem/cxl_type3_stubs.c
index 231dda263f..98292a931c 100644
--- a/hw/mem/cxl_type3_stubs.c
+++ b/hw/mem/cxl_type3_stubs.c
@@ -78,6 +78,10 @@ void qmp_cxl_inject_memory_module_event(const char *path, CxlEventLog log,
uint32_t dirty_shutdown_count,
uint32_t corrected_volatile_error_count,
uint32_t corrected_persist_error_count,
+ const char *component_id,
+ bool has_comp_id_pldm,
+ bool is_comp_id_pldm,
+ uint8_t sub_type,
Error **errp) {}
void qmp_cxl_inject_poison(const char *path, uint64_t start, uint64_t length,
--
2.48.1Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
> From: Shiju Jose <shiju.jose@huawei.com>
>
> CXL spec rev3.2 section 8.2.10.2.1.3 Table 8-50, memory module
> event record has updated with following new fields.
> 1. Validity Flags
> 2. Component Identifier
> 3. Device Event Sub-Type
>
> Add updates for the above spec changes in the CXL memory module
> event reporting and QMP command to inject memory module event.
>
> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> qapi/cxl.json | 12 +++++++++++-
> include/hw/cxl/cxl_events.h | 7 +++++--
> hw/mem/cxl_type3.c | 20 ++++++++++++++++++++
> hw/mem/cxl_type3_stubs.c | 4 ++++
> 4 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/qapi/cxl.json b/qapi/cxl.json
> index 3e4bad4ad0..752d46cda2 100644
> --- a/qapi/cxl.json
> +++ b/qapi/cxl.json
> @@ -242,6 +242,14 @@
> # @corrected-persistent-error-count: Total number of correctable
> # errors in persistent memory
> #
> +# @component-id: Device specific component identifier for the event.
> +# May describe a field replaceable sub-component of the device.
> +#
> +# @is-comp-id-pldm: This flag specifies whether the device-specific
> +# component identifier format follows PLDM.
> +#
> +# @sub-type: Device event sub-type.
> +#
These three seem to be the same in CXLGeneralMediaEvent, CXLDRAMEvent,
and CXLMemModuleEvent. Should they live in their common base type
CXLCommonEventBase?
> # Since: 8.1
> ##
> { 'struct': 'CXLMemModuleEvent',
> @@ -251,7 +259,9 @@
> 'life-used': 'uint8', 'temperature' : 'int16',
> 'dirty-shutdown-count': 'uint32',
> 'corrected-volatile-error-count': 'uint32',
> - 'corrected-persistent-error-count': 'uint32'
> + 'corrected-persistent-error-count': 'uint32',
> + '*component-id': 'str', '*is-comp-id-pldm':'bool',
> + 'sub-type':'uint8'
> }}
>
> ##
[...]
On Mon, 12 Jan 2026 13:23:27 +0100
Markus Armbruster <armbru@redhat.com> wrote:
> Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
>
> > From: Shiju Jose <shiju.jose@huawei.com>
> >
> > CXL spec rev3.2 section 8.2.10.2.1.3 Table 8-50, memory module
> > event record has updated with following new fields.
> > 1. Validity Flags
> > 2. Component Identifier
> > 3. Device Event Sub-Type
> >
> > Add updates for the above spec changes in the CXL memory module
> > event reporting and QMP command to inject memory module event.
> >
> > Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > ---
> > qapi/cxl.json | 12 +++++++++++-
> > include/hw/cxl/cxl_events.h | 7 +++++--
> > hw/mem/cxl_type3.c | 20 ++++++++++++++++++++
> > hw/mem/cxl_type3_stubs.c | 4 ++++
> > 4 files changed, 40 insertions(+), 3 deletions(-)
> >
> > diff --git a/qapi/cxl.json b/qapi/cxl.json
> > index 3e4bad4ad0..752d46cda2 100644
> > --- a/qapi/cxl.json
> > +++ b/qapi/cxl.json
> > @@ -242,6 +242,14 @@
> > # @corrected-persistent-error-count: Total number of correctable
> > # errors in persistent memory
> > #
> > +# @component-id: Device specific component identifier for the event.
> > +# May describe a field replaceable sub-component of the device.
> > +#
> > +# @is-comp-id-pldm: This flag specifies whether the device-specific
> > +# component identifier format follows PLDM.
> > +#
> > +# @sub-type: Device event sub-type.
> > +#
>
> These three seem to be the same in CXLGeneralMediaEvent, CXLDRAMEvent,
> and CXLMemModuleEvent. Should they live in their common base type
> CXLCommonEventBase?
We have documented that base as corresponding to the spec defined
Common event record header and these aren't part of that. We could
invent a CXLMemCommonEventBase that contains the stuff that is shared
for memory types of errors but it would probably just confuse anyone
trying to correlate this stuff with the spec.
There are a lot more event records we don't yet support, or are not
directly injected because they are responses to some other action.
(e.g. dynamic capacity add produces an event but also changes a bunch
of device state)
I'm not sure if we will add direct injection of any of those other
events in future. Some are errors such as MLD Port Event Records,
but reporting those inband makes no sense as normal PCIe error
reporting is used for that. They are to expose what happened to
an out of band monitoring interface (see examples in patch 2
discussion).
Thanks for all your other feedback. We'll resolve that for v3.
Jonathan
>
> > # Since: 8.1
> > ##
> > { 'struct': 'CXLMemModuleEvent',
> > @@ -251,7 +259,9 @@
> > 'life-used': 'uint8', 'temperature' : 'int16',
> > 'dirty-shutdown-count': 'uint32',
> > 'corrected-volatile-error-count': 'uint32',
> > - 'corrected-persistent-error-count': 'uint32'
> > + 'corrected-persistent-error-count': 'uint32',
> > + '*component-id': 'str', '*is-comp-id-pldm':'bool',
> > + 'sub-type':'uint8'
> > }}
> >
> > ##
>
> [...]
>
>
>
Jonathan Cameron <jonathan.cameron@huawei.com> writes: > On Mon, 12 Jan 2026 13:23:27 +0100 > Markus Armbruster <armbru@redhat.com> wrote: > >> Jonathan Cameron <Jonathan.Cameron@huawei.com> writes: >> >> > From: Shiju Jose <shiju.jose@huawei.com> >> > >> > CXL spec rev3.2 section 8.2.10.2.1.3 Table 8-50, memory module >> > event record has updated with following new fields. >> > 1. Validity Flags >> > 2. Component Identifier >> > 3. Device Event Sub-Type >> > >> > Add updates for the above spec changes in the CXL memory module >> > event reporting and QMP command to inject memory module event. >> > >> > Signed-off-by: Shiju Jose <shiju.jose@huawei.com> >> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> >> > --- >> > qapi/cxl.json | 12 +++++++++++- >> > include/hw/cxl/cxl_events.h | 7 +++++-- >> > hw/mem/cxl_type3.c | 20 ++++++++++++++++++++ >> > hw/mem/cxl_type3_stubs.c | 4 ++++ >> > 4 files changed, 40 insertions(+), 3 deletions(-) >> > >> > diff --git a/qapi/cxl.json b/qapi/cxl.json >> > index 3e4bad4ad0..752d46cda2 100644 >> > --- a/qapi/cxl.json >> > +++ b/qapi/cxl.json >> > @@ -242,6 +242,14 @@ >> > # @corrected-persistent-error-count: Total number of correctable >> > # errors in persistent memory >> > # >> > +# @component-id: Device specific component identifier for the event. >> > +# May describe a field replaceable sub-component of the device. >> > +# >> > +# @is-comp-id-pldm: This flag specifies whether the device-specific >> > +# component identifier format follows PLDM. >> > +# >> > +# @sub-type: Device event sub-type. >> > +# >> >> These three seem to be the same in CXLGeneralMediaEvent, CXLDRAMEvent, >> and CXLMemModuleEvent. Should they live in their common base type >> CXLCommonEventBase? > > We have documented that base as corresponding to the spec defined > Common event record header and these aren't part of that. We could > invent a CXLMemCommonEventBase that contains the stuff that is shared > for memory types of errors but it would probably just confuse anyone > trying to correlate this stuff with the spec. > > There are a lot more event records we don't yet support, or are not > directly injected because they are responses to some other action. > (e.g. dynamic capacity add produces an event but also changes a bunch > of device state) > > I'm not sure if we will add direct injection of any of those other > events in future. Some are errors such as MLD Port Event Records, > but reporting those inband makes no sense as normal PCIe error > reporting is used for that. They are to expose what happened to > an out of band monitoring interface (see examples in patch 2 > discussion). I gladly defer to your expert opinion here. We can always factor out later. > Thanks for all your other feedback. We'll resolve that for v3. > > Jonathan [...]
Jonathan Cameron <Jonathan.Cameron@huawei.com> writes:
> From: Shiju Jose <shiju.jose@huawei.com>
>
> CXL spec rev3.2 section 8.2.10.2.1.3 Table 8-50, memory module
> event record has updated with following new fields.
> 1. Validity Flags
> 2. Component Identifier
> 3. Device Event Sub-Type
>
> Add updates for the above spec changes in the CXL memory module
> event reporting and QMP command to inject memory module event.
>
> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> qapi/cxl.json | 12 +++++++++++-
> include/hw/cxl/cxl_events.h | 7 +++++--
> hw/mem/cxl_type3.c | 20 ++++++++++++++++++++
> hw/mem/cxl_type3_stubs.c | 4 ++++
> 4 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/qapi/cxl.json b/qapi/cxl.json
> index 3e4bad4ad0..752d46cda2 100644
> --- a/qapi/cxl.json
> +++ b/qapi/cxl.json
> @@ -242,6 +242,14 @@
##
# @CXLMemModuleEvent:
#
# Event record for a Memory Module Event (CXL r3.0 8.2.9.2.1.3).
#
# @type: Device Event Type. See CXL r3.0 Table 8-45 Memory Module
# Event Record for bit definitions for bit definiions.
#
[...]
> # @corrected-persistent-error-count: Total number of correctable
> # errors in persistent memory
> #
> +# @component-id: Device specific component identifier for the event.
> +# May describe a field replaceable sub-component of the device.
> +#
> +# @is-comp-id-pldm: This flag specifies whether the device-specific
> +# component identifier format follows PLDM.
> +#
> +# @sub-type: Device event sub-type.
> +#
> # Since: 8.1
You're not updating the reference to the CXL spec from 3.0 to 3.2.
Intentional? You do in PATCH 2.
> ##
> { 'struct': 'CXLMemModuleEvent',
> @@ -251,7 +259,9 @@
> 'life-used': 'uint8', 'temperature' : 'int16',
> 'dirty-shutdown-count': 'uint32',
> 'corrected-volatile-error-count': 'uint32',
> - 'corrected-persistent-error-count': 'uint32'
> + 'corrected-persistent-error-count': 'uint32',
> + '*component-id': 'str', '*is-comp-id-pldm':'bool',
> + 'sub-type':'uint8'
> }}
>
> ##
[...]
© 2016 - 2026 Red Hat, Inc.