Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/2195596/?format=api
{ "id": 2195596, "url": "http://patchwork.ozlabs.org/api/patches/2195596/?format=api", "web_url": "http://patchwork.ozlabs.org/project/qemu-devel/patch/20260211103320.2064211-2-cuichao1753@phytium.com.cn/", "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": "<20260211103320.2064211-2-cuichao1753@phytium.com.cn>", "list_archive_url": null, "date": "2026-02-11T10:33:20", "name": "[v3,1/1] mm: numa_memblks: Identify the accurate NUMA ID of CFMW", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "4ace09df86a8f2a748f1c7d13e276dfba177cd2e", "submitter": { "id": 92627, "url": "http://patchwork.ozlabs.org/api/people/92627/?format=api", "name": "Cui Chao", "email": "cuichao1753@phytium.com.cn" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/qemu-devel/patch/20260211103320.2064211-2-cuichao1753@phytium.com.cn/mbox/", "series": [ { "id": 491838, "url": "http://patchwork.ozlabs.org/api/series/491838/?format=api", "web_url": "http://patchwork.ozlabs.org/project/qemu-devel/list/?series=491838", "date": "2026-02-11T10:33:19", "name": "Identify the accurate NUMA ID of CFMW", "version": 3, "mbox": "http://patchwork.ozlabs.org/series/491838/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/2195596/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/2195596/checks/", "tags": {}, "related": [], "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)", "hzbj-icmmx-7; spf=neutral smtp.mail=cuichao175\n 3@phytium.com.cn;" ], "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 4fB0C357Gyz1xpY\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 12 Feb 2026 00:48:47 +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 1vqAZF-0007MX-GT; Wed, 11 Feb 2026 08:47:45 -0500", "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 <cuichao1753@phytium.com.cn>)\n id 1vq7XR-00039i-5X\n for qemu-devel@nongnu.org; Wed, 11 Feb 2026 05:33:41 -0500", "from sgoci-sdnproxy-4.icoremail.net ([129.150.39.64])\n by eggs.gnu.org with esmtp (Exim 4.90_1)\n (envelope-from <cuichao1753@phytium.com.cn>) id 1vq7XO-0001KE-94\n for qemu-devel@nongnu.org; Wed, 11 Feb 2026 05:33:40 -0500", "from prodtpl.icoremail.net (unknown [10.12.1.20])\n by hzbj-icmmx-7 (Coremail) with SMTP id AQAAfwBHT5v1WoxpduYHBw--.791S2;\n Wed, 11 Feb 2026 18:33:25 +0800 (CST)", "from localhost.localdomain (unknown [218.76.62.144])\n by mail (Coremail) with SMTP id AQAAfwDXMO7yWoxptIgaAA--.31566S3;\n Wed, 11 Feb 2026 18:33:23 +0800 (CST)" ], "From": "Cui Chao <cuichao1753@phytium.com.cn>", "To": "Andrew Morton <akpm@linux-foundation.org>", "Cc": "Jonathan Cameron <Jonathan.Cameron@huawei.com>,\n Mike Rapoport <rppt@kernel.org>, Wang Yinfeng <wangyinfeng@phytium.com.cn>,\n dan.j.williams@intel.com,\n Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>,\n Gregory Price <gourry@gourry.net>, David Hildenbrand <david@kernel.org>,\n linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org,\n linux-mm@kvack.org, qemu-devel@nongnu.org,\n Jonathan Cameron <jonathan.cameron@huawei.com>", "Subject": "[PATCH v3 1/1] mm: numa_memblks: Identify the accurate NUMA ID of\n CFMW", "Date": "Wed, 11 Feb 2026 18:33:20 +0800", "Message-Id": "<20260211103320.2064211-2-cuichao1753@phytium.com.cn>", "X-Mailer": "git-send-email 2.33.0", "In-Reply-To": "<20260211103320.2064211-1-cuichao1753@phytium.com.cn>", "References": "<20260211103320.2064211-1-cuichao1753@phytium.com.cn>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit", "X-CM-TRANSID": "AQAAfwDXMO7yWoxptIgaAA--.31566S3", "X-CM-SenderInfo": "pfxlux1drrlkut6sx5pwlxzhxfrphubq/1tbiAQADAGmLkQQCTwAEs8", "X-Coremail-Antispam": "1Uk129KBjvJXoWxKw4kGF4fJw17Kr1kXw1rtFb_yoW7GFy7pa\n 1IqrZYgF4kGry7GF4kZa1DJr1Sv3ZakF43GFW7CrnxuFn0gr18ur4Sqw1YvFWkGryfC3Wr\n XF4Dtw1Yv3WDZaDanT9S1TB71UUUUjDqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj\n DUYxn0WfASr-VFAU7a7-sFnT9fnUUIcSsGvfJ3UbIYCTnIWIevJa73UjIFyTuYvj4RJUUU\n UUUUU", "Received-SPF": "pass client-ip=129.150.39.64;\n envelope-from=cuichao1753@phytium.com.cn; helo=sgoci-sdnproxy-4.icoremail.net", "X-Spam_score_int": "-18", "X-Spam_score": "-1.9", "X-Spam_bar": "-", "X-Spam_report": "(-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001,\n RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,\n RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no", "X-Spam_action": "no action", "X-Mailman-Approved-At": "Wed, 11 Feb 2026 08:47:41 -0500", "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>", "Errors-To": "qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org", "Sender": "qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org" }, "content": "In some physical memory layout designs, the address space of CFMW (CXL\nFixed Memory Window) resides between multiple segments of system memory\nbelonging to the same NUMA node. In numa_cleanup_meminfo, these multiple\nsegments of system memory are merged into a larger numa_memblk. When\nidentifying which NUMA node the CFMW belongs to, it may be incorrectly\nassigned to the NUMA node of the merged system memory.\n\nWhen a CXL RAM region is created in userspace, the memory capacity of\nthe newly created region is not added to the CFMW-dedicated NUMA node.\nInstead, it is accumulated into an existing NUMA node (e.g., NUMA0\ncontaining RAM). This makes it impossible to clearly distinguish\nbetween the two types of memory, which may affect memory-tiering\napplications.\n\nExample memory layout:\n\nPhysical address space:\n 0x00000000 - 0x1FFFFFFF System RAM (node0)\n 0x20000000 - 0x2FFFFFFF CXL CFMW (node2)\n 0x40000000 - 0x5FFFFFFF System RAM (node0)\n 0x60000000 - 0x7FFFFFFF System RAM (node1)\n\nAfter numa_cleanup_meminfo, the two node0 segments are merged into one:\n 0x00000000 - 0x5FFFFFFF System RAM (node0) // CFMW is inside the range\n 0x60000000 - 0x7FFFFFFF System RAM (node1)\n\nSo the CFMW (0x20000000-0x2FFFFFFF) will be incorrectly assigned to node0.\n\nTo address this scenario, accurately identifying the correct NUMA node\ncan be achieved by checking whether the region belongs to both\nnuma_meminfo and numa_reserved_meminfo.\n\n1. Issue Impact and Backport Recommendation:\n\nThis patch fixes an issue observed in QEMU emulation where, during the\ndynamic creation of a CXL RAM region, the memory capacity is not assigned\nto the correct CFMW-dedicated NUMA node. While hardware platforms could\npotentially have such memory configurations, we are not currently aware\nof any such hardware. This issue leads to:\n\n Failure of the memory tiering mechanism: The system is designed to\n treat System RAM as fast memory and CXL memory as slow memory. For\n performance optimization, hot pages may be migrated to fast memory\n while cold pages are migrated to slow memory. The system uses NUMA\n IDs as an index to identify different tiers of memory. If the NUMA\n ID for CXL memory is calculated incorrectly and its capacity is\n aggregated into the NUMA node containing System RAM (i.e., the node\n for fast memory), the CXL memory cannot be correctly identified. It\n may be misjudged as fast memory, thereby affecting performance\n optimization strategies.\n\n Inability to distinguish between System RAM and CXL memory even for\n simple manual binding: Tools like |numactl|and other NUMA policy\n utilities cannot differentiate between System RAM and CXL memory,\n making it impossible to perform reasonable memory binding.\n\n Inaccurate system reporting: Tools like |numactl -H|would display\n memory capacities that do not match the actual physical hardware\n layout, impacting operations and monitoring.\n\nThis issue affects all users utilizing the CXL RAM functionality who\nrely on memory tiering or NUMA-aware scheduling.\n\nTherefore, I recommend backporting this patch to all stable kernel\nseries that support dynamic CXL region creation.\n\n2. Why a Kernel Update is Recommended Over a Firmware Update:\n\nIn the scenario of dynamic CXL region creation, the association between\nthe memory's HPA range and its corresponding NUMA node is established\nwhen the kernel driver performs the commit operation. This is a runtime,\nOS-managed operation where the platform firmware cannot intervene to\nprovide a fix.\n\nConsidering factors like hardware platform architecture, memory\nresources, and others, such a physical address layout can indeed occur.\nThis patch does not introduce risk; it simply correctly handles the\nNUMA node assignment for CXL RAM regions within such a physical address\nlayout.\n\nThus, I believe a kernel fix is necessary.\n\nFixes: 779dd20cfb56 (\"cxl/region: Add region creation support\")\nSigned-off-by: Cui Chao <cuichao1753@phytium.com.cn>\nReviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>\n---\n mm/numa_memblks.c | 9 +++++----\n 1 file changed, 5 insertions(+), 4 deletions(-)", "diff": "diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c\nindex 5b009a9cd8b4..0892d532908c 100644\n--- a/mm/numa_memblks.c\n+++ b/mm/numa_memblks.c\n@@ -568,15 +568,16 @@ static int meminfo_to_nid(struct numa_meminfo *mi, u64 start)\n int phys_to_target_node(u64 start)\n {\n \tint nid = meminfo_to_nid(&numa_meminfo, start);\n+\tint reserved_nid = meminfo_to_nid(&numa_reserved_meminfo, start);\n \n \t/*\n-\t * Prefer online nodes, but if reserved memory might be\n-\t * hot-added continue the search with reserved ranges.\n+\t * Prefer online nodes unless the address is also described\n+\t * by reserved ranges, in which case use the reserved nid.\n \t */\n-\tif (nid != NUMA_NO_NODE)\n+\tif (nid != NUMA_NO_NODE && reserved_nid == NUMA_NO_NODE)\n \t\treturn nid;\n \n-\treturn meminfo_to_nid(&numa_reserved_meminfo, start);\n+\treturn reserved_nid;\n }\n EXPORT_SYMBOL_GPL(phys_to_target_node);\n \n", "prefixes": [ "v3", "1/1" ] }