On 08.04.2024 05:19, Henry Wang wrote: > On 4/4/2024 5:38 PM, Jan Beulich wrote: >> On 03.04.2024 10:16, Henry Wang wrote: >>> --- a/xen/include/public/memory.h >>> +++ b/xen/include/public/memory.h >>> @@ -41,6 +41,11 @@ >>> #define XENMEMF_exact_node(n) (XENMEMF_node(n) | >>> XENMEMF_exact_node_request) >>> /* Flag to indicate the node specified is virtual node */ >>> #define XENMEMF_vnode (1<<18) >>> +/* >>> + * Flag to force populate physmap to use pages from domheap instead of 1:1 >>> + * or static allocation. >>> + */ >>> +#define XENMEMF_force_heap_alloc (1<<19) >> As before, a separate new sub-op would look to me as being the cleaner >> approach, avoiding the need to consume a bit position for something not >> even going to be used on all architectures. > > Like discussed in v2, I doubt that if introducing a new sub-op, the > helpers added to duplicate mainly populate_physmap() and the toolstack > helpers would be a good idea.
I'm curious what amount of duplication you still see left. By suitably adding a new parameter, there should be very little left. > Similarly as the way that we do for the > MEMF_force_heap_alloc, if in the future we run out of the bit positions, > can't we reuse this bit for different architectures as an alias? Or > maybe we can even alias it now? I view this as far less desirable in the public interface. Jan
