Re: [PATCH v1 2/3] xen/dom0less: refactor architecture-specific DomU construction

["Orzel, Michal" <michal.orzel@xxxxxxx>]

On 15/05/2025 02:07, Stefano Stabellini wrote:
> On Wed, 14 May 2025, Orzel, Michal wrote:
>>> Sure. But my point is rather more that static memory is not a feature 
>>> described by the Arm Arm. Instead, it is a feature of Xen that is ti to 
>>> device-tree. So inherently there is no reason to be implemented in arch/arm.
>> I agree, it can and should be made common. But exposing only callers makes no
>> sense at all for me. Callers should be exposed together with feature code 
>> movement.
> 
> [...]
> 
>>>>> back to Arm for then moving back to common potentially in a few weeks 
>>>>> time.
>>>> What about static memory code? With the recent Oleksii code movement, the 
>>>> inline
>>>> helpers like allocate_static_memory() became unreachable when the feature 
>>>> is
>>>> disabled and the main purpose for helpers was to avoid ifdefery.
>>>
>>> Sorry I am not sure which part you are referring to.
>> With the current code, allocate_static_memory(), assign_static_memory_11()
>> callers (that were moved to common) are protected with #ifdef. This causes 
>> the
>> helpers defined in case CONFIG_STATIC_MEMORY is not defined to be unreachable
>> (see static-memory.h).
> 
> At a high level I agree with Julien, this is the kind of feature that
> should be common. In fact, I would even say that I consider the related
> device tree bindings common.  But looking at the code movements and the
> #ifdef's, I think that as of today, this patch series is improving
> things.
I've said multiple times already that I also agree that static mem/shmem should
be common. It was not the point of this discussion. My only concern is that it
should be done in a proper way and not in 5% like it was done recently that also
resulted in issues I mentioned above. Therefore I also (hence my tag) believe we
should accept it.

~Michal