Add a small status query so orchestration layers can check whether a tagged
extent is still pending, committed, or no longer present after a release
request.
Introduce the ExtentStatus QAPI struct and the
cxl-release-dynamic-capacity-status command.
Signed-off-by: Alireza Sanaee <alireza.sanaee@huawei.com>
---
hw/mem/cxl_type3.c | 85 ++++++++++++++++++++++++++++++++++++++++
hw/mem/cxl_type3_stubs.c | 10 +++++
qapi/cxl.json | 46 ++++++++++++++++++++++
3 files changed, 141 insertions(+)
diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
index d5fa8a530a..8999b36e61 100644
--- a/hw/mem/cxl_type3.c
+++ b/hw/mem/cxl_type3.c
@@ -2635,6 +2635,91 @@ void cxl_remove_memory_alias(CXLType3Dev *dcd, struct CXLFixedWindow *fw,
dcd->dc.direct_mr_bitmap &= ~(1u << hdm_id);
}
+/*
+ * This function allows for a simple check to make sure that
+ * our extent is removed. It can be used by an orchestration layer.
+ */
+ExtentStatus *
+qmp_cxl_release_dynamic_capacity_status(const char *path,
+ uint16_t hid, uint8_t rid,
+ const char *tag,
+ Error **errp)
+{
+ Object *obj;
+ CXLType3Dev *dcd;
+ CXLDCExtentList *list = NULL;
+ CXLDCExtent *ent;
+ QemuUUID uuid_req;
+ ExtentStatus *res;
+
+ obj = object_resolve_path_type(path, TYPE_CXL_TYPE3, NULL);
+ if (!obj) {
+ error_setg(errp, "Unable to resolve CXL type 3 device");
+ return NULL;
+ }
+
+ dcd = CXL_TYPE3(obj);
+ if (!dcd->dc.num_regions) {
+ error_setg(errp, "No dynamic capacity support from the device");
+ return NULL;
+ }
+
+ if (rid >= dcd->dc.num_regions) {
+ error_setg(errp, "Region id is too large");
+ return NULL;
+ }
+
+ if (!tag) {
+ error_setg(errp, "Tag must be valid");
+ return NULL;
+ }
+
+ list = &dcd->dc.extents;
+ qemu_uuid_parse(tag, &uuid_req);
+ res = g_new0(ExtentStatus, 1);
+
+ /* Check committed extents */
+ QTAILQ_FOREACH(ent, list, node) {
+ QemuUUID uuid_ext;
+ g_autofree char *uuid_str = NULL;
+ memcpy(&uuid_ext.data, ent->tag, sizeof(ent->tag));
+ if (qemu_uuid_is_equal(&uuid_req, &uuid_ext)) {
+ uuid_str = qemu_uuid_unparse_strdup(&uuid_ext);
+ res->status = g_strdup("Committed");
+ res->message =
+ g_strdup_printf("Found committed extent with tag %s dpa 0x%"
+ PRIx64 " len 0x%" PRIx64,
+ uuid_str, ent->start_dpa, ent->len);
+ return res;
+ }
+ }
+
+ /* Check pending extents (not yet committed by kernel) */
+ {
+ CXLDCExtentGroup *group;
+ QTAILQ_FOREACH(group, &dcd->dc.extents_pending, node) {
+ QTAILQ_FOREACH(ent, &group->list, node) {
+ QemuUUID uuid_ext;
+ g_autofree char *uuid_str = NULL;
+ memcpy(&uuid_ext.data, ent->tag, sizeof(ent->tag));
+ if (qemu_uuid_is_equal(&uuid_req, &uuid_ext)) {
+ uuid_str = qemu_uuid_unparse_strdup(&uuid_ext);
+ res->status = g_strdup("Pending");
+ res->message =
+ g_strdup_printf("Found pending extent with tag %s"
+ " dpa 0x%" PRIx64 " len 0x%" PRIx64,
+ uuid_str, ent->start_dpa, ent->len);
+ return res;
+ }
+ }
+ }
+ }
+
+ res->status = g_strdup("Released");
+ res->message = g_strdup_printf("Tag %s released or not found", tag);
+ return res;
+}
+
static void ct3_class_init(ObjectClass *oc, const void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
diff --git a/hw/mem/cxl_type3_stubs.c b/hw/mem/cxl_type3_stubs.c
index 98292a931c..17f9414142 100644
--- a/hw/mem/cxl_type3_stubs.c
+++ b/hw/mem/cxl_type3_stubs.c
@@ -127,3 +127,13 @@ void qmp_cxl_release_dynamic_capacity(const char *path, uint16_t host_id,
{
error_setg(errp, "CXL Type 3 support is not compiled in");
}
+
+ExtentStatus *qmp_cxl_release_dynamic_capacity_status(const char *path,
+ uint16_t host_id,
+ uint8_t region,
+ const char *tag,
+ Error **errp)
+{
+ error_setg(errp, "CXL Type 3 support is not compiled in");
+ return NULL;
+}
diff --git a/qapi/cxl.json b/qapi/cxl.json
index 81d6198ba0..53325ba530 100644
--- a/qapi/cxl.json
+++ b/qapi/cxl.json
@@ -636,3 +636,49 @@
},
'features': [ 'unstable' ]
}
+
+##
+# @ExtentStatus:
+# This is an object that describes the status of an extent.
+#
+# @status: String indicating the overall result, e.g. "success".
+# @message: Human-readable description of the outcome.
+#
+# Since: 9.1
+##
+{ 'struct': 'ExtentStatus',
+ 'data': { 'status': 'str', 'message': 'str' }
+}
+
+##
+# @cxl-release-dynamic-capacity-status:
+#
+# This commands checks if an extent tag has been released or not.
+#
+# @path: path to the CXL Dynamic Capacity Device in the QOM tree.
+#
+# @host-id: The "Host ID" field as defined in Compute Express Link
+# (CXL) Specification, Revision 3.1, Table 7-71.
+#
+# @region: The "Region Number" field as defined in Compute Express
+# Link Specification, Revision 3.1, Table 7-71. Valid range
+# is from 0-7.
+#
+# @tag: The "Tag" field as defined in Compute Express Link (CXL)
+# Specification, Revision 3.1, Table 7-71.
+#
+# Features:
+#
+# @unstable: For now this command is subject to change.
+#
+# Since: 9.1
+##
+{ 'command': 'cxl-release-dynamic-capacity-status',
+ 'data': { 'path': 'str',
+ 'host-id': 'uint16',
+ 'region': 'uint8',
+ 'tag': 'str'
+ },
+ 'features': [ 'unstable' ],
+ 'returns': 'ExtentStatus'
+}
--
2.50.1 (Apple Git-155)I'm a near-complete CXL ignoramus, and beg your patience.
Alireza Sanaee <alireza.sanaee@huawei.com> writes:
> Add a small status query so orchestration layers can check whether a tagged
> extent is still pending, committed, or no longer present after a release
> request.
Why would they want to check?
What is a "release request"?
>
> Introduce the ExtentStatus QAPI struct and the
> cxl-release-dynamic-capacity-status command.
>
> Signed-off-by: Alireza Sanaee <alireza.sanaee@huawei.com>
[...]
> diff --git a/qapi/cxl.json b/qapi/cxl.json
> index 81d6198ba0..53325ba530 100644
> --- a/qapi/cxl.json
> +++ b/qapi/cxl.json
> @@ -636,3 +636,49 @@
> },
> 'features': [ 'unstable' ]
> }
> +
> +##
> +# @ExtentStatus:
Blank line here, please.
> +# This is an object that describes the status of an extent.
> +#
> +# @status: String indicating the overall result, e.g. "success".
What are the possible values? Are they defined in some spec?
> +# @message: Human-readable description of the outcome.
Intended use?
> +#
> +# Since: 9.1
11.1 most likely.
> +##
> +{ 'struct': 'ExtentStatus',
> + 'data': { 'status': 'str', 'message': 'str' }
> +}
> +
> +##
> +# @cxl-release-dynamic-capacity-status:
> +#
> +# This commands checks if an extent tag has been released or not.
Use imperative mood to describe commands: "Check whether an extent tag
has been released."
> +#
> +# @path: path to the CXL Dynamic Capacity Device in the QOM tree.
We commonly call such members @qom-path.
> +#
> +# @host-id: The "Host ID" field as defined in Compute Express Link
> +# (CXL) Specification, Revision 3.1, Table 7-71.
> +#
> +# @region: The "Region Number" field as defined in Compute Express
> +# Link Specification, Revision 3.1, Table 7-71. Valid range
> +# is from 0-7.
> +#
> +# @tag: The "Tag" field as defined in Compute Express Link (CXL)
> +# Specification, Revision 3.1, Table 7-71.
I guess the command interrogates something called "extent", and the
something is related to the CXL device at @path in the QOM tree.
Correct?
How is it related? Is it a part of the device?
I further guess multiple extends can be so related, and @host-id,
@region, and @tag identify select the one we want to interrogate.
Correct?
> +#
> +# Features:
> +#
> +# @unstable: For now this command is subject to change.
The conventional language is "This command is experimental."
> +#
> +# Since: 9.1
11.1 most likely.
> +##
> +{ 'command': 'cxl-release-dynamic-capacity-status',
> + 'data': { 'path': 'str',
> + 'host-id': 'uint16',
> + 'region': 'uint8',
> + 'tag': 'str'
> + },
> + 'features': [ 'unstable' ],
> + 'returns': 'ExtentStatus'
Swap these two lines, please.
> +}
On Thu, 26 Mar 2026 16:15:40 +0100
Markus Armbruster <armbru@redhat.com> wrote:
Hi Markus,
This commit adds a test command to check whether an extent (a piece of memory region) has been released or not by the guest.
The process of removal is highly asynchronous, that's why I needed to add a new command to check it.
I would be happy to drop this patch, as this is extra.
Thanks,
Ali
> I'm a near-complete CXL ignoramus, and beg your patience.
>
> Alireza Sanaee <alireza.sanaee@huawei.com> writes:
>
> > Add a small status query so orchestration layers can check whether a tagged
> > extent is still pending, committed, or no longer present after a release
> > request.
>
> Why would they want to check?
>
> What is a "release request"?
>
> >
> > Introduce the ExtentStatus QAPI struct and the
> > cxl-release-dynamic-capacity-status command.
> >
> > Signed-off-by: Alireza Sanaee <alireza.sanaee@huawei.com>
>
> [...]
>
> > diff --git a/qapi/cxl.json b/qapi/cxl.json
> > index 81d6198ba0..53325ba530 100644
> > --- a/qapi/cxl.json
> > +++ b/qapi/cxl.json
> > @@ -636,3 +636,49 @@
> > },
> > 'features': [ 'unstable' ]
> > }
> > +
> > +##
> > +# @ExtentStatus:
>
> Blank line here, please.
>
> > +# This is an object that describes the status of an extent.
> > +#
> > +# @status: String indicating the overall result, e.g. "success".
>
> What are the possible values? Are they defined in some spec?
>
> > +# @message: Human-readable description of the outcome.
>
> Intended use?
>
> > +#
> > +# Since: 9.1
>
> 11.1 most likely.
>
> > +##
> > +{ 'struct': 'ExtentStatus',
> > + 'data': { 'status': 'str', 'message': 'str' }
> > +}
> > +
> > +##
> > +# @cxl-release-dynamic-capacity-status:
> > +#
> > +# This commands checks if an extent tag has been released or not.
>
> Use imperative mood to describe commands: "Check whether an extent tag
> has been released."
>
> > +#
> > +# @path: path to the CXL Dynamic Capacity Device in the QOM tree.
>
> We commonly call such members @qom-path.
>
> > +#
> > +# @host-id: The "Host ID" field as defined in Compute Express Link
> > +# (CXL) Specification, Revision 3.1, Table 7-71.
> > +#
> > +# @region: The "Region Number" field as defined in Compute Express
> > +# Link Specification, Revision 3.1, Table 7-71. Valid range
> > +# is from 0-7.
> > +#
> > +# @tag: The "Tag" field as defined in Compute Express Link (CXL)
> > +# Specification, Revision 3.1, Table 7-71.
>
> I guess the command interrogates something called "extent", and the
> something is related to the CXL device at @path in the QOM tree.
> Correct?
>
> How is it related? Is it a part of the device?
>
> I further guess multiple extends can be so related, and @host-id,
> @region, and @tag identify select the one we want to interrogate.
> Correct?
>
> > +#
> > +# Features:
> > +#
> > +# @unstable: For now this command is subject to change.
>
> The conventional language is "This command is experimental."
>
> > +#
> > +# Since: 9.1
>
> 11.1 most likely.
>
> > +##
> > +{ 'command': 'cxl-release-dynamic-capacity-status',
> > + 'data': { 'path': 'str',
> > + 'host-id': 'uint16',
> > + 'region': 'uint8',
> > + 'tag': 'str'
> > + },
> > + 'features': [ 'unstable' ],
> > + 'returns': 'ExtentStatus'
>
> Swap these two lines, please.
>
> > +}
>
>
Alireza Sanaee <alireza.sanaee@huawei.com> writes: > On Thu, 26 Mar 2026 16:15:40 +0100 > Markus Armbruster <armbru@redhat.com> wrote: > > Hi Markus, > > This commit adds a test command to check whether an extent (a piece of memory region) has been released or not by the guest. > The process of removal is highly asynchronous, that's why I needed to add a new command to check it. > > I would be happy to drop this patch, as this is extra. So your motivation for adding the command is "just" testing. Correct? Can you think of other uses? In particular, would a management application need this query to monitor removal? The description of feature @unstable may need to be adjusted for the answers we work out here. > > Thanks, > Ali
On Sat, 28 Mar 2026 07:01:51 +0100 Markus Armbruster <armbru@redhat.com> wrote: +CC Ira Hi Markus, Please look inline. I believe Ira might be able to help and we can see what he thinks. > Alireza Sanaee <alireza.sanaee@huawei.com> writes: > > > On Thu, 26 Mar 2026 16:15:40 +0100 > > Markus Armbruster <armbru@redhat.com> wrote: > > > > Hi Markus, > > > > This commit adds a test command to check whether an extent (a piece of memory region) has been released or not by the guest. > > The process of removal is highly asynchronous, that's why I needed to add a new command to check it. > > > > I would be happy to drop this patch, as this is extra. > > So your motivation for adding the command is "just" testing. Correct? I wrote tests to make sure extents were released, and I used this QMP command to check. Now there is background about extents where DCD was developed in Linux by @Ira, CCed [1]. In the DCD extent tracking section of the CXL spec, I see some commands related to getting the extent list, maybe Ira can comment here. To be fair, knowing if an extent was released or not is a useful information in general from orchestrator perspective. [1] https://patchew.org/linux/20250413-dcd-type2-upstream-v9-0-1d4911a0b365@intel.com/ > > Can you think of other uses? > > In particular, would a management application need this query to monitor > removal? I think management will get a signal on the removal given the schema in Ira's Linux kernel patchset. I do not think this is implemented in QEMU at least (I might be missing something). > > The description of feature @unstable may need to be adjusted for the > answers we work out here. Absolutely. > > > > > Thanks, > > Ali > >
Alireza Sanaee <alireza.sanaee@huawei.com> writes:
> On Sat, 28 Mar 2026 07:01:51 +0100
> Markus Armbruster <armbru@redhat.com> wrote:
>
> +CC Ira
>
> Hi Markus,
>
> Please look inline. I believe Ira might be able to help and we can see what he thinks.
>
>> Alireza Sanaee <alireza.sanaee@huawei.com> writes:
>>
>> > On Thu, 26 Mar 2026 16:15:40 +0100
>> > Markus Armbruster <armbru@redhat.com> wrote:
>> >
>> > Hi Markus,
>> >
>> > This commit adds a test command to check whether an extent (a piece of memory region) has been released or not by the guest.
>> > The process of removal is highly asynchronous, that's why I needed to add a new command to check it.
>> >
>> > I would be happy to drop this patch, as this is extra.
>>
>> So your motivation for adding the command is "just" testing. Correct?
>
> I wrote tests to make sure extents were released, and I used this QMP command to check.
As long as this is the only known use case, we want
# @unstable: This command is meant for debugging.
in the QAPI schema.
> Now there is background about extents where DCD was developed in Linux by @Ira, CCed [1].
>
> In the DCD extent tracking section of the CXL spec, I see some commands
> related to getting the extent list, maybe Ira can comment here. To be fair, knowing if an extent
> was released or not is a useful information in general from orchestrator perspective.
>
> [1] https://patchew.org/linux/20250413-dcd-type2-upstream-v9-0-1d4911a0b365@intel.com/
If we believe there are other uses, but we're unsure the command
actually serves them:
# @unstable: This command is experimental.
>> Can you think of other uses?
>>
>> In particular, would a management application need this query to monitor
>> removal?
>
> I think management will get a signal on the removal given the schema in Ira's Linux kernel
> patchset. I do not think this is implemented in QEMU at least (I might be missing something).
I'm getting a feeling of "this is underbaked" :) But that's for the CXL
maintainers to judge.
>> The description of feature @unstable may need to be adjusted for the
>> answers we work out here.
>
> Absolutely.
>
>>
>> >
>> > Thanks,
>> > Ali
>>
>>
© 2016 - 2026 Red Hat, Inc.