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/[email protected]/ 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. Thanks again for the review and feedback! Best regards / Bien cordialement / Saludos / Liebe Grüße, With warm greetings from Vienna/Austria, Bernhard
