Cover Letter Detail
Show a cover letter.
GET /api/covers/2216046/?format=api
{ "id": 2216046, "url": "http://patchwork.ozlabs.org/api/covers/2216046/?format=api", "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=api", "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=api", "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=api", "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(-)" }