{"id":2216046,"url":"http://patchwork.ozlabs.org/api/covers/2216046/?format=json","web_url":"http://patchwork.ozlabs.org/project/qemu-devel/cover/20260325184259.366-1-alireza.sanaee@huawei.com/","project":{"id":14,"url":"http://patchwork.ozlabs.org/api/projects/14/?format=json","name":"QEMU Development","link_name":"qemu-devel","list_id":"qemu-devel.nongnu.org","list_email":"qemu-devel@nongnu.org","web_url":"","scm_url":"","webscm_url":"","list_archive_url":"","list_archive_url_format":"","commit_url_format":""},"msgid":"<20260325184259.366-1-alireza.sanaee@huawei.com>","list_archive_url":null,"date":"2026-03-25T18:42:48","name":"[QEMU,0/9] Application Specific Tagged Memory Support in CXL Type 3 Devices","submitter":{"id":90159,"url":"http://patchwork.ozlabs.org/api/people/90159/?format=json","name":"Alireza Sanaee","email":"alireza.sanaee@huawei.com"},"mbox":"http://patchwork.ozlabs.org/project/qemu-devel/cover/20260325184259.366-1-alireza.sanaee@huawei.com/mbox/","series":[{"id":497484,"url":"http://patchwork.ozlabs.org/api/series/497484/?format=json","web_url":"http://patchwork.ozlabs.org/project/qemu-devel/list/?series=497484","date":"2026-03-25T18:42:48","name":"Application Specific Tagged Memory Support in CXL Type 3 Devices","version":1,"mbox":"http://patchwork.ozlabs.org/series/497484/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/covers/2216046/comments/","headers":{"Return-Path":"<qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org>","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":"legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)","Received":["from lists.gnu.org (lists.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fgwmS55vVz1y1K\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 26 Mar 2026 05:44:07 +1100 (AEDT)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from <qemu-devel-bounces@nongnu.org>)\n\tid 1w5TCN-00024L-Mq; Wed, 25 Mar 2026 14:43:24 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <alireza.sanaee@huawei.com>)\n id 1w5TCM-00024B-8F\n for qemu-devel@nongnu.org; Wed, 25 Mar 2026 14:43:22 -0400","from frasgout.his.huawei.com ([185.176.79.56])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <alireza.sanaee@huawei.com>)\n id 1w5TCJ-0005qH-Cz\n for qemu-devel@nongnu.org; Wed, 25 Mar 2026 14:43:21 -0400","from mail.maildlp.com (unknown [172.18.224.107])\n by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4fgwl43pFjzJ46F4;\n Thu, 26 Mar 2026 02:42:56 +0800 (CST)","from dubpeml500005.china.huawei.com (unknown [7.214.145.207])\n by mail.maildlp.com (Postfix) with ESMTPS id 78CD340584;\n Thu, 26 Mar 2026 02:43:05 +0800 (CST)","from a2303103017.china.huawei.com (10.47.66.203) by\n dubpeml500005.china.huawei.com (7.214.145.207) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.2.1544.11; Wed, 25 Mar 2026 18:43:04 +0000"],"To":"<qemu-devel@nongnu.org>","CC":"<anisa.su@samsung.com>, <armbru@redhat.com>, <berrange@redhat.com>,\n <eblake@redhat.com>, <jonathan.cameron@huawei.com>,\n <linux-cxl@vger.kernel.org>, <linuxarm@huawei.com>, <lizhijian@fujitsu.com>,\n <mst@redhat.com>, <pbonzini@redhat.com>, <gourry@gourry.net>,\n <nifan.cxl@gmail.com>, <me@linux.beauty>","Subject":"[QEMU PATCH 0/9] Application Specific Tagged Memory Support in CXL\n Type 3 Devices","Date":"Wed, 25 Mar 2026 18:42:48 +0000","Message-ID":"<20260325184259.366-1-alireza.sanaee@huawei.com>","X-Mailer":"git-send-email 2.51.0.windows.2","MIME-Version":"1.0","Content-Transfer-Encoding":"8bit","Content-Type":"text/plain","X-Originating-IP":"[10.47.66.203]","X-ClientProxiedBy":"lhrpeml500011.china.huawei.com (7.191.174.215) To\n dubpeml500005.china.huawei.com (7.214.145.207)","Received-SPF":"pass client-ip=185.176.79.56;\n envelope-from=alireza.sanaee@huawei.com; helo=frasgout.his.huawei.com","X-Spam_score_int":"-41","X-Spam_score":"-4.2","X-Spam_bar":"----","X-Spam_report":"(-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3,\n RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,\n RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,\n SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development <qemu-devel.nongnu.org>","List-Unsubscribe":"<https://lists.nongnu.org/mailman/options/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>","List-Archive":"<https://lists.nongnu.org/archive/html/qemu-devel>","List-Post":"<mailto:qemu-devel@nongnu.org>","List-Help":"<mailto:qemu-devel-request@nongnu.org?subject=help>","List-Subscribe":"<https://lists.nongnu.org/mailman/listinfo/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=subscribe>","Reply-to":"Alireza Sanaee <alireza.sanaee@huawei.com>","From":"Alireza Sanaee via qemu development <qemu-devel@nongnu.org>","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"},"content":"Hi,\n\nThis series is a rework of the earlier RFC posted at:\nhttps://lore.kernel.org/all/20251127225526.700-1-alireza.sanaee@huawei.com/\n\nThe overall goal is still to support application-specific tagged memory\nfor CXL Type 3 dynamic capacity, but the backend model is now different.\n\nThe earlier RFC introduced a dedicated tagged memory backend object.\nThis version does not. Instead, the first patch adds a `tag` property\nto generic host memory backends, and the rest of the series teaches the\nCXL Type 3 DC flow to find and hook up those tagged backends lazily at\nruntime.\n\nIn practice, a device may now be created with `dc-regions-total-size`\nand no `volatile-dc-memdev`. When add-capacity is requested with a tag,\nthe tagged host memory backend is looked up, validated, and only mapped\nafter host acceptance. The committed extent keeps the backend and fixed\nwindow metadata so that:\n\n - direct alias mapping can be installed for the performant path,\n - teardown can happen correctly at release time, and\n - tag-based removal can locate and release extents by tag.\n\nAssumptions, limitations and reasons behind it:\n\n 1. Each lazy-backed extent maps to exactly one tagged host memory\n    backend. In VM scenarios, we just need to add a backend which has\n    one extent representing the entire backend tied to one region. If\n    more extents required then more regions can be added.\n 2. Partial release of a backend-backed extent is rejected. If a\n    backend is represented by the one extent then partial release of\n    a region does not makes sense.\n 3. The current lazy flow only supports a single extent per add\n    request. This can be changed if required later.\n\nThis series contains:\n\n - add generic host memory backend tag support;\n - allow creating DC-only Type 3 devices with total capacity but no\n   backing device at init time;\n - wire tagged host memory backends into the DC add flow;\n - store per-extent backend and fixed-window metadata;\n - map the backend after host acceptance;\n - add the direct alias fast path for accesses;\n - tear down aliases and lazy mappings on release;\n - add tag-based removal support; and\n - add a status QMP helper for orchestration layers.\n\nTested with two tagged `memory-backend-ram` objects and QMP-driven add\nand release flows, including tag-based release.\n\nExample flow\n============\n\nBelow is a short tutorial-style example based on the earlier RFC, but\nupdated for the current design where generic host memory backends carry\nthe tag.\n\n1. Start QEMU with a Type 3 device that advertises dynamic capacity via\n   `dc-regions-total-size`, without an initial `volatile-dc-memdev`.\n\n   -device cxl-type3,bus=root_port13,id=cxl-vmem0,num-dc-regions=1, \\\n           dc-regions-total-size=4G\n\n2. Create tagged backends at runtime with QMP:\n\n{\n    \"execute\": \"object-add\",\n    \"arguments\": {\n        \"qom-type\": \"memory-backend-ram\",\n        \"id\": \"tm0\",\n        \"size\": 1073741824,\n        \"share\": true,\n        \"tag\": \"5be13bce-ae34-4a77-b6c3-16df975fcf1a\"\n    }\n}\n\n{\n    \"execute\": \"object-add\",\n    \"arguments\": {\n        \"qom-type\": \"memory-backend-ram\",\n        \"id\": \"tm1\",\n        \"size\": 1073741824,\n        \"share\": true,\n        \"tag\": \"6be13bce-ae34-4a77-b6c3-16df975fcf1a\"\n    }\n}\n\n3. Add capacity by tag:\n\n{\n    \"execute\": \"cxl-add-dynamic-capacity\",\n    \"arguments\": {\n        \"path\": \"/machine/peripheral/cxl-vmem0\",\n        \"host-id\": 0,\n        \"selection-policy\": \"prescriptive\",\n        \"region\": 0,\n        \"tag\": \"5be13bce-ae34-4a77-b6c3-16df975fcf1a\",\n        \"extents\": [\n            {\n                \"offset\": 0,\n                \"len\": 1073741824\n            }\n        ]\n    }\n}\n\nAfter the host accepts the extent, the tagged backend is mapped and the\ndirect alias path becomes active for the committed extent.\n\n4. Release by tag:\n\n{\n    \"execute\": \"cxl-release-dynamic-capacity\",\n    \"arguments\": {\n        \"path\": \"/machine/peripheral/cxl-vmem0\",\n        \"host-id\": 0,\n        \"removal-policy\": \"tag-based\",\n        \"tag\": \"5be13bce-ae34-4a77-b6c3-16df975fcf1a\",\n        \"region\": 0,\n        \"extents\": [\n            {\n                \"offset\": 0,\n                \"len\": 1073741824\n            }\n        ]\n    }\n}\n\n5. Query whether the tagged extent is still present:\n\n{\n    \"execute\": \"cxl-release-dynamic-capacity-status\",\n    \"arguments\": {\n        \"path\": \"/machine/peripheral/cxl-vmem0\",\n        \"host-id\": 0,\n        \"tag\": \"5be13bce-ae34-4a77-b6c3-16df975fcf1a\",\n        \"region\": 0\n    }\n}\n\nFor the Ira patchset from Intel, I allowed UUIDs in the kernel-side\nflow, and that change is available here:\nhttps://github.com/sarsanaee/linux/tree/allow_uuid_ira\n\nDepends-on:\nhttps://lore.kernel.org/all/20260318171918.146-1-alireza.sanaee@huawei.com/\n\nDepends-on:\nhttps://lore.kernel.org/all/20250413-dcd-type2-upstream-v9-0-1d4911a0b365@intel.com/\n\n--\nAlireza Sanaee\n\nAlireza Sanaee (9):\n  hw/mem: Add tag support to generic host memory backends\n  hw/cxl: Allow initializing type3 device with no backing device\n  hw/cxl: Hook up tagged host memory backends at runtime for DC extents\n  hw/cxl: Carry backend metadata in DC extent records\n  hw/cxl: Map lazy memory backend after host acceptance\n  hw/cxl: Create direct fixed-window aliases for accepted extents\n  hw/cxl: Add release-time teardown for direct-mapped extents\n  hw/cxl: Add tag-based dynamic-capacity release support\n  hw/cxl: Add QMP status query for dynamic-capacity extent release\n\n backends/hostmem.c          |  72 +++++++\n hw/cxl/cxl-host.c           |   6 +\n hw/cxl/cxl-mailbox-utils.c  | 223 ++++++++++++++++++++--\n hw/mem/cxl_type3.c          | 361 +++++++++++++++++++++++++++++++-----\n hw/mem/cxl_type3_stubs.c    |  10 +\n include/hw/cxl/cxl_device.h |  41 +++-\n include/system/hostmem.h    |   2 +\n qapi/cxl.json               |  46 +++++\n qapi/qom.json               |   3 +\n tests/qtest/qom-test.c      |   8 +-\n 10 files changed, 703 insertions(+), 69 deletions(-)"}