From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2F555FD5320 for ; Fri, 27 Feb 2026 09:40:14 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1242543.1542939 (Exim 4.92) (envelope-from ) id 1vvuK2-0002W1-1y; Fri, 27 Feb 2026 09:39:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1242543.1542939; Fri, 27 Feb 2026 09:39:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vvuK1-0002Vu-Tc; Fri, 27 Feb 2026 09:39:45 +0000 Received: by outflank-mailman (input) for mailman id 1242543; Fri, 27 Feb 2026 09:39:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vvuK0-0002Vf-Hg for xen-devel@lists.xenproject.org; Fri, 27 Feb 2026 09:39:44 +0000 Received: from mail178-23.suw51.mandrillapp.com (mail178-23.suw51.mandrillapp.com [198.2.178.23]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3d64ccc0-13c0-11f1-9ccf-f158ae23cfc8; Fri, 27 Feb 2026 10:39:41 +0100 (CET) Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail178-23.suw51.mandrillapp.com (Mailchimp) with ESMTP id 4fMjwD1HT4z35hg4R for ; Fri, 27 Feb 2026 09:39:40 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id f157163a010b4c50a07224fe7c27dba4; Fri, 27 Feb 2026 09:39:40 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3d64ccc0-13c0-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1772185180; x=1772455180; bh=Y1nYe09ke51CdH/6D0EdVY0J4b99jSrb6M8aLy27Luw=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=ixcy01PAgLxpT7zq1TLjxcINUb6xHhyryIzEEcdvkHQ7nhnBz5edykZoFT/OXwB0k L+c30A9jtq6AGqpmLqUYqimYsykXlm7Cmi8KqlBZ9jxoDK5EmIXXUp6vrjYG6Miepc tUf26rUVSH44ouA1o0iQL2DGth6oYd2FaiqIxeTFkEYqb83qJdP5lT6+lpTT7qR0bz CNP6VvgJKOdhMwQw/eFvR+rVt5z4nl52Y6bbdRD91ILqLasUBP0ISEmgBx2dMxm1w/ HxUmNmHoSZS23i8/+VUPx4PGWrOLUxxF4+7EELas9cSW4997G6bFs/BA8e+2bmoRSy 2DKW29X9FJBiw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1772185180; x=1772445680; i=teddy.astie@vates.tech; bh=Y1nYe09ke51CdH/6D0EdVY0J4b99jSrb6M8aLy27Luw=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=tOz1SgFXNvE1E4F39kU6xCtAo8ZDv9AtxkBsAcGdwIpghj8WDYHibAEZIZOK5Cs7v +vA0lx7U1BN2V1IydQ2lc/aN/9ceda0BXMI98IJGHyP8S2q+nseObqGPFJCGntZt7b oiGFd6d0a7WDm+JxWToeeoCKunIibakgd5h9xevPITf5YglP5if321+a/pM/zQyOv3 DN+1mFnbPvkoJSp3poqih2X5Qn3MV83XZXSvYxq1O42U/7bmCgVe5BZyfPj4DXzfKo CTA3hsl2gHNA3BTVoZM40bGhxuwQDbfANSUgebwfN33Tv5qinWJvlRsZ+a+UTLIOUh yE74SFH30N5+A== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v4=2005/10]=20xen/domain:=20Add=20DOMCTL=20handler=20for=20claiming=20memory=20with=20NUMA=20awareness?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1772185177224 Message-Id: To: "Bernhard Kaindl" , xen-devel@lists.xenproject.org Cc: "Andrew Cooper" , "Anthony PERARD" , "Michal Orzel" , "Jan Beulich" , "Julien Grall" , "Roger Pau Monne" , "Stefano Stabellini" , "Daniel P. Smith" References: <656ff614-9165-49ce-8c55-0cfad33d4ed6@vates.tech> In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.f157163a010b4c50a07224fe7c27dba4?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260227:md Date: Fri, 27 Feb 2026 09:39:40 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 27/02/2026 =C3=A0 00:21, Bernhard Kaindl a =C3=A9crit=C2=A0: > On 26/02/2026 =C3=A0 22:19, Teddy Astie a =C3=A9crit : >> Le 26/02/2026 =C3=A0 15:54, Bernhard Kaindl a =C3=A9crit : >>> Add a DOMCTL handler for claiming memory with NUMA awareness. It >>> rejects claims when LLC coloring (does not support claims) is enabled >>> and translates the public constant to the internal NUMA_NO_NODE. >>> >>> The request is forwarded to domain_set_outstanding_pages() for the >>> actual claim processing. The handler uses the same XSM hook as the >>> legacy XENMEM_claim_pages hypercall. >>> >>> While the underlying infrastructure currently supports only a single >>> claim, the public hypercall interface is designed to be extensible for >>> multiple claims in the future without breaking the API. >> I'm not sure about the idea of introducing a new hypercall for this >> operation. Though I may be missing some context about the reasons of >> introducing a new hypercall. >> >> XENMEM_claim_pages doesn't have actual support for NUMA, but the >> hypercall interface seems to define it (e.g you can pass >> XENMEMF_exact_node(n) to mem_flags). Would it be preferable instead to >> make XENMEM_claim_pages aware of NUMA-related XENMEMF flags ? > > Hello Teddy, > > Thank you for your review =E2=80=94 much appreciated. > > Updating the do_memory_op(XENMEM_claim_pages) handler to accept a node > parameter, as you suggested, is indeed a practical way to retrofit this > feature into existing Xen builds. That=E2=80=99s also the approach we too= k in > v1 of this series: > > * https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg01127.h= tml > * https://patchew.org/Xen/20250314172502.53498-1-alejandro.vallejo@cloud.= com/ > > We are currently using this approach also in the XS9 Public Preview: > > * https://www.xenserver.com/downloads/xs9-preview > > That said, during review, Roger Pau Monn=C3=A9 suggested that for upstrea= m > inclusion, we should introduce a new hypercall API with support for > multi-node claims, even if the initial infrastructure only handles > a single node. See: > > * https://lists.xenproject.org/archives/html/xen-devel/2025-06/msg00484.h= tml > > He raised the concern that the current interface effectively constrains > domains to be allocated from one node at a time, or to sequence claims > across nodes, which undermines the purpose of claims. > > Instead, he proposed that the hypercall interface would ideally allow > making multi-node claims atomically, rather than requiring multiple > calls with rollback in case of failure. > > I favour Roger=E2=80=99s position as well: I think we should aim for a cl= ean > and extensible interface that supports claims across multiple nodes > in a single call. Otherwise, we risk having to introduce yet another > hypercall later when a real-world scenario requires multi-node claims. > > On the implementation side, a reliable first-come, first-served mechanism > for multi-node claims will require serialisation in the central claim pat= h. > Currently, the global heap_lock provides that protection, and it would > naturally cover the creation of a multi-node claim under a single lock, > ensuring atomicity and consistent behaviour. > Ok thanks. Should we state that the old interface is "deprecated" (somehow), and that people should take a look at XEN_DOMCTL_claim_memory instead, especially if they need a NUMA-aware interface ? That could be a note on the XENMEM_claim_memory hypercall. > Thanks again for the review and feedback! > > Best regards / Bien cordialement / Saludos / Liebe Gr=C3=BC=C3=9Fe, > > With warm greetings from Vienna/Austria, > Bernhard Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech