Re: [PATCH v3 4/4] xen/memory, tools: Avoid hardcoding GUEST_MAGIC_BASE in init-dom0less

[Jan Beulich <jbeulich@xxxxxxxx>]

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