Re: [PATCH qemu v2 5/5] hw/cxl/events: Updates for rev3.2 memory module event record

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

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'
> >              }}
> >  
> >  ##  
> 
> [...]
> 
> 
>