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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 13 Feb 2025, Grygorii Strashko wrote:
> 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?

Yes, they should 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 :(

The good news is that we managed to align the hyperlaunch DT with the
dom0less DT and they are now compatible in the last incarnation of the
patch series. The ability to use the dom0less domain nodes (not the
legacy dom0 nodes) and still be able to specify a dom0 is something that
hyperlaunch had from the start and will be of great benefit to ARM as
well.