Re: [RFC PATCH] arm: dom0: allow static memory configuration

[Grygorii Strashko <grygorii_strashko@xxxxxxxx>]

Hi Stefano,

On 13.02.25 00:11, Stefano Stabellini wrote:
> On Wed, 12 Feb 2025, Grygorii Strashko wrote:
> > The Arm Xen allocates memory to place Dom0 following the logic described in
> > allocate_memory_11() function which is a bit complicated with major
> > requirement to place Dom0 within the first 128MB of RAM and below 4G. But
> > this doesn't guarantee it will be placed at the same physical base address
> > even between two boots with different configuration (changing the Kernel
> > image size or Initrd size may cause Dom0 base address to change).
> >
> > In case of "thin Dom0" use case, when Dom0 implemented with RTOS like
> > Zephyr, which doesn't use dynamic device-tree parsing, such behavior
> > causes a lot of inconvenience as it is required to perform modification and
> > recompiling of Zephyr image to adjust memory layout.
> >
> > It also prevents from using Initrd with Zephyr, for example, as it's
> > expected to be placed at known, fixed address in memory.
> >
> > This RFC patch introduces the possibility to place Dom0 at fixed physical
> > base address, by checking if "chosen" node contains property
> > "xen,static-mem" and places Dom0 exactly at the specified memory chunk.
> >
> > The implementation follows the same approach as for the static, direct-mapped
> > guest domain in case of dom0less boot.
> >
> > Signed-off-by: Grygorii Strashko <grygorii_strashko@xxxxxxxx>
> I fully support this idea and the addition of static memory support to
> Dom0. However, I would suggest a different approach regarding the device
> tree binding. Specifically, I would prefer to avoid introducing
> additional top-level properties for Dom0 under /chosen.
That's was major point declaring it RFC.

> Instead, we should create a domain node for Dom0 under /chosen, like we
> do for other DomUs. Jason is currently working on adding a capability
> properties to the Dom0less domain nodes, allowing us to specify whether
> a domain is the hardware domain, the control domain, or both
> (effectively making it Dom0). Once this is in place, we can use
> static-mem for Dom0 in the same way as always.
Good to here that, I assume it can wait (a bit) then.

But please note that our requirement here to allow static memory for both 
dom0less and
non-dom0less boot, so here is the question - will bindings and 
dom0/hwdom/control
domain setup be generic?

Honestly, for ARM, the discrepancies between boot modes and Xen DT definitions
(and actually toolstack) are very confusing :( And now there is also
hyperlaunch on the horizon :(

[...]

BR,
-grygorii