Re: [PATCH v4 25/25] xen/riscv: add initial dom0less infrastructure support

[Jan Beulich <jbeulich@suse.com>]

On 26.06.2026 17:46, Oleksii Kurochko wrote:
> Enable dom0less support for RISC-V by selecting HAS_DOM0LESS and
> providing the minimal architecture hooks required by the common
> dom0less infrastructure.
> 
> Add stub implementations for architecture-specific helpers used when
> building domains from the device tree. These allow the generic
> dom0less code to build and let a basic DomU be constructed on RISC-V.
> construct_hwdom() and make_hypervisor_node() are still stubs returning
> an error: Dom0/hwdom construction isn't supported yet, and the
> hypervisor node generation (needed by domains with
> DOM0LESS_ENHANCED_NO_XS set) is not implemented. Both are marked with
> a TODO and are not reached by the currently supported configurations.
> 
> Provide missing helpers and definitions required by the domain
> construction code, including domain bitness helpers and the
> p2m_set_allocation() prototype.
> 
> Additionally define the guest magic memory region (GUEST_MAGIC_BASE /
> GUEST_MAGIC_SIZE) in asm/guest-layout.h. The base is arbitrary; the
> only constraint is that the region must not overlap guest RAM or the
> emulated device regions. It is placed in the unused gap below
> GUEST_RAM0_BASE (0x80000000); the constraints are documented next to
> the #define-s.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

Nevertheless, ...

> --- a/xen/arch/riscv/include/asm/guest-layout.h
> +++ b/xen/arch/riscv/include/asm/guest-layout.h
> @@ -32,4 +32,16 @@
>  #define GUEST_RAM_BANK_BASES   { GUEST_RAM0_BASE, GUEST_RAM1_BASE }
>  #define GUEST_RAM_BANK_SIZES   { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE }
>  
> +/*
> + * The guest magic region holds Xen-reserved pages mapped into the guest's
> + * physical address space (shared info, grant table, etc.). The only real
> + * constraint is that the GUEST_MAGIC_SIZE-byte region must not overlap
> + * guest RAM (the GUEST_RAMx banks) or the emulated device regions defined
> + * above; the exact base is otherwise arbitrary. Here it is placed in the
> + * unused gap below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM
> + * bank would work equally well.
> + */
> +#define GUEST_MAGIC_BASE  _UL(0x79000000)
> +#define GUEST_MAGIC_SIZE  _UL(0x01000000)

... while 16Mb may seem a lot, it feels pretty little for 64-bit guests.
Even in just Sv39 mode they have ample VA space to map a bigger region.
(As iirc indicated before, a static upper bound looks questionable to me
anyway.)

Jan