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

[Markus Armbruster <armbru@redhat.com>]

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

[...]