Re: [PATCH v4 05/10] xen/domain: Add DOMCTL handler for claiming memory with NUMA awareness

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

Le 27/02/2026 à 00:21, Bernhard Kaindl a écrit :
> On 26/02/2026 à 22:19, Teddy Astie a écrit :
>> Le 26/02/2026 à 15:54, Bernhard Kaindl a écrit :
>>> 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 — 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’s also the approach we took in
> v1 of this series:
>
> * https://lists.xenproject.org/archives/html/xen-devel/2025-03/msg01127.html
> * https://patchew.org/Xen/20250314172502.53498-1-alejandro.vallejo@xxxxxxxxx/
>
> 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é suggested that for upstream
> 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.html
>
> 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’s position as well: I think we should aim for a clean
> 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 path.
> 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üße,
>
> With warm greetings from Vienna/Austria,
> Bernhard

Teddy


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech