[QEMU PATCH 0/9] Application Specific Tagged Memory Support in CXL Type 3 Devices

[Alireza Sanaee via qemu development <qemu-devel@nongnu.org>]

Hi,

This series is a rework of the earlier RFC posted at:
https://lore.kernel.org/all/20251127225526.700-1-alireza.sanaee@huawei.com/

The overall goal is still to support application-specific tagged memory
for CXL Type 3 dynamic capacity, but the backend model is now different.

The earlier RFC introduced a dedicated tagged memory backend object.
This version does not. Instead, the first patch adds a `tag` property
to generic host memory backends, and the rest of the series teaches the
CXL Type 3 DC flow to find and hook up those tagged backends lazily at
runtime.

In practice, a device may now be created with `dc-regions-total-size`
and no `volatile-dc-memdev`. When add-capacity is requested with a tag,
the tagged host memory backend is looked up, validated, and only mapped
after host acceptance. The committed extent keeps the backend and fixed
window metadata so that:

 - direct alias mapping can be installed for the performant path,
 - teardown can happen correctly at release time, and
 - tag-based removal can locate and release extents by tag.

Assumptions, limitations and reasons behind it:

 1. Each lazy-backed extent maps to exactly one tagged host memory
    backend. In VM scenarios, we just need to add a backend which has
    one extent representing the entire backend tied to one region. If
    more extents required then more regions can be added.
 2. Partial release of a backend-backed extent is rejected. If a
    backend is represented by the one extent then partial release of
    a region does not makes sense.
 3. The current lazy flow only supports a single extent per add
    request. This can be changed if required later.

This series contains:

 - add generic host memory backend tag support;
 - allow creating DC-only Type 3 devices with total capacity but no
   backing device at init time;
 - wire tagged host memory backends into the DC add flow;
 - store per-extent backend and fixed-window metadata;
 - map the backend after host acceptance;
 - add the direct alias fast path for accesses;
 - tear down aliases and lazy mappings on release;
 - add tag-based removal support; and
 - add a status QMP helper for orchestration layers.

Tested with two tagged `memory-backend-ram` objects and QMP-driven add
and release flows, including tag-based release.

Example flow
============

Below is a short tutorial-style example based on the earlier RFC, but
updated for the current design where generic host memory backends carry
the tag.

1. Start QEMU with a Type 3 device that advertises dynamic capacity via
   `dc-regions-total-size`, without an initial `volatile-dc-memdev`.

   -device cxl-type3,bus=root_port13,id=cxl-vmem0,num-dc-regions=1, \
           dc-regions-total-size=4G

2. Create tagged backends at runtime with QMP:

{
    "execute": "object-add",
    "arguments": {
        "qom-type": "memory-backend-ram",
        "id": "tm0",
        "size": 1073741824,
        "share": true,
        "tag": "5be13bce-ae34-4a77-b6c3-16df975fcf1a"
    }
}

{
    "execute": "object-add",
    "arguments": {
        "qom-type": "memory-backend-ram",
        "id": "tm1",
        "size": 1073741824,
        "share": true,
        "tag": "6be13bce-ae34-4a77-b6c3-16df975fcf1a"
    }
}

3. Add capacity by tag:

{
    "execute": "cxl-add-dynamic-capacity",
    "arguments": {
        "path": "/machine/peripheral/cxl-vmem0",
        "host-id": 0,
        "selection-policy": "prescriptive",
        "region": 0,
        "tag": "5be13bce-ae34-4a77-b6c3-16df975fcf1a",
        "extents": [
            {
                "offset": 0,
                "len": 1073741824
            }
        ]
    }
}

After the host accepts the extent, the tagged backend is mapped and the
direct alias path becomes active for the committed extent.

4. Release by tag:

{
    "execute": "cxl-release-dynamic-capacity",
    "arguments": {
        "path": "/machine/peripheral/cxl-vmem0",
        "host-id": 0,
        "removal-policy": "tag-based",
        "tag": "5be13bce-ae34-4a77-b6c3-16df975fcf1a",
        "region": 0,
        "extents": [
            {
                "offset": 0,
                "len": 1073741824
            }
        ]
    }
}

5. Query whether the tagged extent is still present:

{
    "execute": "cxl-release-dynamic-capacity-status",
    "arguments": {
        "path": "/machine/peripheral/cxl-vmem0",
        "host-id": 0,
        "tag": "5be13bce-ae34-4a77-b6c3-16df975fcf1a",
        "region": 0
    }
}

For the Ira patchset from Intel, I allowed UUIDs in the kernel-side
flow, and that change is available here:
https://github.com/sarsanaee/linux/tree/allow_uuid_ira

Depends-on:
https://lore.kernel.org/all/20260318171918.146-1-alireza.sanaee@huawei.com/

Depends-on:
https://lore.kernel.org/all/20250413-dcd-type2-upstream-v9-0-1d4911a0b365@intel.com/

--
Alireza Sanaee

Alireza Sanaee (9):
  hw/mem: Add tag support to generic host memory backends
  hw/cxl: Allow initializing type3 device with no backing device
  hw/cxl: Hook up tagged host memory backends at runtime for DC extents
  hw/cxl: Carry backend metadata in DC extent records
  hw/cxl: Map lazy memory backend after host acceptance
  hw/cxl: Create direct fixed-window aliases for accepted extents
  hw/cxl: Add release-time teardown for direct-mapped extents
  hw/cxl: Add tag-based dynamic-capacity release support
  hw/cxl: Add QMP status query for dynamic-capacity extent release

 backends/hostmem.c          |  72 +++++++
 hw/cxl/cxl-host.c           |   6 +
 hw/cxl/cxl-mailbox-utils.c  | 223 ++++++++++++++++++++--
 hw/mem/cxl_type3.c          | 361 +++++++++++++++++++++++++++++++-----
 hw/mem/cxl_type3_stubs.c    |  10 +
 include/hw/cxl/cxl_device.h |  41 +++-
 include/system/hostmem.h    |   2 +
 qapi/cxl.json               |  46 +++++
 qapi/qom.json               |   3 +
 tests/qtest/qom-test.c      |   8 +-
 10 files changed, 703 insertions(+), 69 deletions(-)

-- 
2.50.1 (Apple Git-155)