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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.

So my Ack was not at all a statement to say that the feature should be
Arm-only. To the contrary. But it was only a practical consideration
about the state of the code right now.

I do think that RISC-V should gain support for it at some point and we
should share the code as much as possible.